How to update your project to the latest OpenXava?
Download the latest OpenXava distribution and uncompress it in a new location.
If you current OpenXava version is older than 5.0 add a new empty Java project from Eclipse in your workspace called Addons.
Stop your Eclipse.
Remove the Addons (since v5.0) and OpenXava projects from your workspace.
Copy the Addons and OpenXava projects from the workspace of the new OpenXava to yours.
Start your Eclipse.
Build All (Ctrl-B).
Execute the updateOX ant target of your project.
Refresh (with F5) your project.
Revise the instructions below.
If your application fails:
Stop tomcat and remove the temp and work folders of Tomcat (inside the Eclipse use Clean Tomcat Work Directory... on your server in Server view).
Remove your application from Tomcat and add it again.
Migration from OpenXava 5.8.1 to OpenXava 5.9
New actions in collections (for JUnit tests)
The collections have new actions available for the users (CollectionCopyPaste.cut and CollectionCopyPaste.paste), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new CollectionCopyPaste.cut action. CollectionCopyPast.paste is hidden by default, so you can ignore it. Moreover, List.sumColum now is always present even if the collection is empty:
String[] actions = {"Navigation.previous",
"Navigation.first",
"Navigation.next",
"CRUD.new",
"CRUD.save",
"CRUD.delete",
"CRUD.refresh",
"Mode.list",
"Mode.split",
"Collection.new",
"Collection.removeSelected",
"CollectionCopyPaste.cut", // ADD THIS ENTRY"Print.generatePdf",
"Print.generateExcel",
"List.filter",
"List.orderBy",
"List.sumColumn", // ALWAYS PRESENT, EVEN IF COLLECTION IS EMPTY"List.changeColumnName"};
assertActions(actions);
Booleans are rendered with their label instead of a check in lists
Until now when a boolean was true in the list, the cell shows a check icon and if it is false nothing. From now on, if the boolean is true its label will be shown in the cell, that is for a property named paid, "Paid" will be shown in the cell. This change does not require any modification in your application code, however maybe you have to change some of your JUnit tests for lists and collections. For example, if you have the next line in your test:
assertValueInList(2, 4, "Yes");
You should change it by:
assertValueInList(2, 4, "Paid");
If the property label is "Paid".
And for the false case, you should change:
assertValueInList(2, 4, "No");
By:
assertValueInList(2, 4, "");
On the other hand if you want to keep the old behavior, just add the next entry in your editors.xml file:
Note the use of BooleanIconListFormatter for list formatter.
Welcome page and Sign In page are separated
Now the content of welcome.jsp is shown when you go to the root of the application. welcome.jsp fills all the page, so you should modify your current welcome.jsp to include the <head>, import the needed CSSs and include a link to the Sign In page (m/SignIn). Look at Addons/web/naviox/welcome.jsp as example.
Migration from OpenXava 5.8 to OpenXava 5.8.1
No issues.
Migration from OpenXava 5.7.1 to OpenXava 5.8
New actions in list mode (for JUnit tests)
The list mode has new actions available for the users (List.changeColumnName and ImportData.importData), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new List.changeColumnName and ImportData.importData actions:
Delete action is not available while creating a new element (for JUnit tests)
In v5.8 when the user clicks on New the Delete action is hidden. This does not affect your application code but if you use assertActions() in your tests maybe you have to adapt them:
Moreover, if you want that the search action comes back use the new SearchForCRUD controller that just contains the classic seach action. To define a module with search in application.xml add the SearchForCRUD controller:
<modulename="Delivery"><modelname="Delivery"/><controllername="Typical"/><controllername="SearchForCRUD"/><!-- ADD THIS LINE --></module>
Another option si to define it in controllers.xml in this way:
<controllername="Author"><extendscontroller="Typical"/><extendscontroller="SearchForCRUD"/><!-- ADD THIS LINE --><actionname="doSomething"class="com.mycompany.test.actions.DoSomethingAction"/></controller>
Even if you add the search action back with SearchForCRUD you have to change your JUnit tests because search is no longer in CRUD but in SearchForCRUD. Therefore you have to change:
execute("CRUD.search");
By:
execute("SearchForCRUD.search");
Also we have a TypicalWithSearch controller that have all the Typical action plus search, just as the old Typical. If you want to use it by default write the next code at the beginning of your application.xml:
Modules with no rows starts executing new action (for JUnit tests)
You should touch JUnit tests with modules without rows, because they now starts in detail mode. For example, you should change a code like this:
publicvoid testCreateExamWithAtLeastOneQuestion()throwsException{
assertListRowCount(0);// NOW THIS LINE FAILS
execute("CRUD.new");
setValue("name", "ADMISSION");
execute("CRUD.save");
...
}
If the module has no rows, now it starts in detail mode so the first line will fail. We can just change to list mode at the beginning:
publicvoid testCreateExamWithAtLeastOneQuestion()throwsException{
execute("Mode.list");// ADD THIS LINE
assertListRowCount(0);
execute("CRUD.new");
setValue("name", "ADMISSION");
execute("CRUD.save");
...
}
Or if you test goes directly to detail mode, like in this example, just remove the first part of the test:
publicvoid testCreateExamWithAtLeastOneQuestion()throwsException{// assertListRowCount(0); // REMOVE THIS LINE// execute("CRUD.new"); // REMOVE THIS LINE
setValue("name", "ADMISSION");
execute("CRUD.save");
...
}
Migration from OpenXava 5.7 to OpenXava 5.7.1
No issues.
Migration from OpenXava 5.6.1 to OpenXava 5.7
Action List.changeConfigurationName renamed as List.changeConfiguration (for JUnit tests)
The list action List.changeConfigurationName now is List.changeConfiguration, therefore if you test for all present actions in your junit tests, you need to modify the name of this action:
privateString[] listActions = {"Mode.detailAndFirst",
"Mode.split",
"List.filter",
"List.orderBy",
"List.viewDetail",
"List.hideRows",
"List.sumColumn",
// "List.changeConfigurationName" // REMOVE THIS ENTRY"List.changeConfiguration"// ADD THIS ENTRY};
assertActions(listActions);
Improved default properties for list and collections (for JUnit tests)
Until now when @Tab for list, or @ListProperties for collections, is omitted by default OpenXava shows all the plain properties of the entity. Since v5.7 when @Tab/@ListProperties is not present the properties to show are the plain ones, the ids of the references, the name, description or title of the references or if not present the first not id property of the reference. Moreover, the plain properties that are just oids are excluded.
For example, if we have this class without @Tab:
In previous versions we get in list: year, number, date, files
In v5.7 we get: year, number, date, customer.number, customer.name
If you have JUnit tests againts entities without @Tab maybe you'll have to adapt them.
@NewAction no longer define the add action in regular @OneToMany collections
Since v5.7 @OneToMany collections without cascade REMOVE have available at the same time a 'New' action to create new elements and a 'Add' action to add elements from existing ones. Before v5.7 only the 'Add' action was available and it could be defined using @NewAction. Now we have a new annotation, @AddAction, for 'Add' action and we use the old @NewAction only for 'New' action.
You should change @NewAction by @AddAction in collections without cascade REMOVE. Change:
Note, now it's not "Collection.view" but "Collection.edit".
Automatic label for references in list optimized (for JUnit tests)
When in a list we have a property from a reference and the property name is "name", "description" or "title", the property name is omitted, OpenXava shows just the reference name. That is, instead of "Name of Customer" now is just "Customer". This does not affect your application code at all, but if you test list labels in your JUnit tests you should adapt them.
Change this:
assertLabelInList(4, "Name of Customer");
By this:
assertLabelInList(4, "Customer");
Migration from OpenXava 5.6 to OpenXava 5.6.1
No issues.
Migration from OpenXava 5.5.1 to OpenXava 5.6
The action ExtendedPrint.myReports is no longer available by default (for JUnit tests)
Therefore if you test for all present actions in your JUnit tests, you need to modify it removing ExtendedPrint.myReports from the list:
privateString[] listActions = {"Print.generatePdf",
"Print.generateExcel",
// REMOVE THIS LINE "ExtendedPrint.myReports","CRUD.new",
"CRUD.deleteSelected",
...
};
assertActions(listActions);
Though the action is not available by default, it still exists in OpenXava and works perfectly. Indeed there is a new controller TypicalExtendedPrint to facilitate its use. If you want to continue using the My reports feature just change Typical by TypicalExtendedPrint in your application.xml and controllers.xml, even you can declare it as default controller.
New action in list (for junit tests)
The list has a new action available for the users (List.changeConfigurationName), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new List.changeConfigurationName action:
Needed to call super inside setUp() of tests before using JPA
Since v5.5.1 the JPA initialization ModuleTestBase tests is done in the setUp() method, so if you use JPA inside a setUp() method you have to call super before. That is, if you have a code like this in your test:
protectedvoid setUp()throwsException{
createEntitiesUsingJPA();// Now it fails, because JPA is not still initializedsuper.setUp();}
Change it by:
protectedvoid setUp()throwsException{super.setUp();// JPA is initialized here
createEntitiesUsingJPA();}
Migration from OpenXava 5.4.1 to OpenXava 5.5
@DescriptionsList combos are not longer HTML select (only if you use HtmlUnit API)
Combos for @DescriptionsList are now created with a HTML input text plus some JavaScript code and CSS to emulate a combo. This does not require any change in your application code, it even does not require that you change your jUnit tests if you just use the ModuleTestBase provided methods. However, if you use the HtmlUnit API directly, for example by means of getHtmlPage() or getWebClient() in your tests, and you manage a @DescriptionList combo. Then you have to adjust your code, changing:
HtmlInput comboInput = form.getInputByName("ox_MyApp_MyModule__myReference___id");
comboInput.setValueAttribute("TheValue");((HtmlInput) comboInput.getPreviousElementSibling()).setValueAttribute("Something");// A trick to avoid that JavaScript reset the real value((HtmlInput) comboInput.getNextElementSibling()).setValueAttribute("Something");// A trick to avoid that JavaScript reset the real value
Migration from OpenXava 5.4 to OpenXava 5.4.1
No issues.
Migration from OpenXava 5.3.2 to OpenXava 5.4
Icons instead of images for actions
Since v5.4 the standard actions of OpenXava use icons from Material Design Icons instead of gif or png images. The image attribute of <action/> in controllers.xml continue to work as always, however we have a new attribute icon that is the one used in the standard actions. The effect is that in your application all the standard actions will use the new monochrome icons and your own actions will use the old colorful gif and png images. This mix could be a little ugly, to fix it just change image by icon in your actions. For example, change:
To see all available icons look at Material Design Icons.
On the other hand, if your prefer to continue with the old fashion color icons, just add the next line in xava.properties:
useIconsInsteadOfImages=false
Then all the actions, included the standard ones, will use the old colorful images.
Migration from OpenXava 5.3.1 to OpenXava 5.3.2
No issues.
Migration from OpenXava 5.3 to OpenXava 5.3.1
HSQLDB jar moved from OpenXavaTest to OpenXava
If you reference this jar you have to change the path. For example, if you uses HSQLDB in some of your projects, you should change in updateSchema target of your build.xml this:
If you use JPA API or basic use of Hibernate API you have to do nothing. However, if you use advanced Hibernate features maybe this upgrade affects you.
For example, if you have your own Hibernate types (UserType), you have to change in your type definition this:
Of course, if you call these methods you have to adapt the calling code too. For example, a code like this:
((UserType) hibernateType).nullSafeSet(ps, o, 1);
Now it would be:
((UserType) hibernateType).nullSafeSet(ps, o, 1, null);
Note that sending a null for the new extra parameter is enough.
Moreover, instead of Hibernate.INTEGER you have to use IntegerType.INSTANCE.
The way of registering events has changed, it affects you only if you use XML components with the JPA API. In this case you have to remove the event registration from the persistence.xml, as following:
Also if you use XML components you no longer can have a reference used as key if the value does not exist in the referenced table. This case is no longer allowed by Hibernate. This case has never been supported in JPA. You should think in a different way of solving your issue, such as adding an autogenerated key or creating the corresponding row in the referenced table.
With Hibernate 4.3 the default way of releasing connections has changed, so you could find a "Could not open connection error". To avoid it add the next entry to your persistence.xml:
<persistence-unitname="default">
...
<properties>
...
<!-- Add the next entry --><propertyname="hibernate.connection.release_mode"value="after_transaction"/></properties></persistence-unit>
Hibernate Validator 3 dropped
Until now we have included both, the old Hibernate Validator 3 and the latest Hibernate Validator version in OpenXava distribution for maximum backward compatibility. Unfortunately Hibernate 4.3 does not support Hibernate Validator 3, so we have to remove it from OpenXava.
If you just use validation annotations as @Max, @Length, @Size, etc. it's enough to change the imports, change:
In the case of @Digits apart of changing the above imports you have to change the parameter names, changing this:
@Digits(integerDigits=10, fractionalDigits=6)
By:
@Digits(integer=10, fraction=6)
You cannot longer use InvalidStateException of Hibernate Validator 3. Therefore, if you use it to throw a validation error from your entity or action you have to change it by other exception. For example, a code like this:
If you have defined your own validator with the Old Hibernate Validator you should rewrite it using the Bean Validation standard. Don't worry, converting it is very easy. In your annotation change @ValidatorClass by @Constraint and add groups() and payload(), thus:
@Constraint(validatedBy = MyValidator.class)// Instead of @ValidatorClass(PropertyValidatorValidator.class)public @interface MyAnnotation {
...
// Add the next codeClass<?>[] groups()default{};Class<?extends Payload>[] payload()default{};}
@Required, @PropertyValidator and @EntityValidator are Bean Validation restriction
Before, they were Hibernate Validator 3 restrictions. If you do your own commit and try to catch the validation exception you have to change the exception to catch. If you have a code like this:
Hibernate 4.3 uses a different way for looking the JNDI resources that works fine with Tomcat 7.0.27 (and better) and Tomcat 6.0.36 (and better) but fails with previous versions. This is not a bug of Hibernate but a Tomcat bug. Fortunately, there is a trick to make the new Hibernate works even with older Tomcat versions, just add a // to the JNDI name. That is, if you're using a Tomcat version previous to 7.0.27 or 6.0.36 just change in your persistence.xml this:
Note the // before comp. If you use JNDI names in other places you shoud change them too. The good thing is that newer Tomcat versions also work in this way, so if you use always this notation your application will work in any Tomcat.
EL libraries upgrade for Tomcat 6
If you're using Tomcat 6 copy el-api.jar and jasper-el.jar from the Tomcat lib folder included in OpenXava (or any Tomcat 7) to the lib folder of your Tomcat 6. This is required by the latest Hibernate Validator version.
Automated Business Logic (ABL) library dropped
Unfortunately, ABL does not support Hibernate 4.3. Moreover, ABL has been discontinued since 2012, so it will not support Hibernate 4.3 in the future. Therefore, we have not other option but removing ABL from OpenXava distribution. Fortunately, moving the logic in ABL annotations to Java code is easy. For example, if you have an ABL logic class like this:
This affects to generateSchema not to updateSchema. If you have a generateSchema target in your build.xml, add schema.path, as following:
<!-- Generates the schema from scratch. Shows it in console, but does not execute it --><targetname="generateSchema"><antantfile="../OpenXava/build.xml"target="generateSchemaJPA"><propertyname="persistence.unit"value="junit"/><!-- ADD THE NEXT LINE FOR V5.3 --><propertyname="schema.path"value="../OpenXavaTest/lib/hsqldb.jar"/></ant></target>
Migration from OpenXava 5.2 to OpenXava 5.2.1
Entity from View has nulls for non-existing references
Until v5.2 all references of the entity obtained via getView().getEntity() have value, even if the references do not exist. It was producing a very odd bug because JPA tries to save transient objects as references. Since v5.2.1, empty references are null, this is more natural (it works in the same way when you get the object from database) and it solves the above bug.
If you have code that relies in this behavior you must change it. That is, you have to make changes like the next one:
Invoice invoice = (Invoice) getView().getEntity();if(invoice.getCustomer().getNumber() == 0){// In v5.2 if customer is empty an empty customer is returned
By:
Invoice invoice = (Invoice) getView().getEntity();if(invoice.getCustomer() == null){// In v5.2.1 if customer is empty a null is returned
Migration from OpenXava 5.1.x to OpenXava 5.2
HtmlUnit upgraded to 2.15
If you use HtmlUnit directly from your jUnit test by means of getHtmlPage() or getWebClient() you should adapt your code to the new HtmlUnit 2.15 API. For example, you should change:
With versions previous to 5.1 when product.number changes unitPrice is recalculated only if it has not value yet. Since version 5.1 unitPrice is recalculated always that product.number changes.
This new behavior is more natural, so if you do not change anything your user just will have a better behavior for his applications. Anyways, maybe you want that the value would be calculated only the first time, just like before. In this case you should rewrite your logic using @OnChage, that is you should change the above code by this:
Now it's required that the user signs in before executing a module so your current jUnit tests will fail. To solve this disable the login mechanism adding the next entries to your naviox.properties file in properties folder:
autologinUser=adminautologinPassword=admin
In this way your tests will run fine without recode them.
Another option is to leave the login mechanism active and to add the login logic in your test:
Executing standalone modules is no longer available by default
When you go to /MyApplication/modules/MyModule with your browser, the module is shown with menus and login included. This is not a problem at all, because the menus are very lightweight and login can be disable with autologinUser and autologinPassword in naviox.properties. Moreover, inside Liferay the modules work as usual.
But if for some reason you prefer to work in the old way you can deactivate login and menus and use the old visual style for your modules in OpenXava 5. To do it edit the web.xml file of OpenXava project and remove:
With the above changes in OpenXava/web.xml you have removed the menus and login. You must execute updateOX ant target to update the web.xml of your project.
For using the visual style of OpenXava 4 add the next entries to xava.properties of your project:
When you access to an OpenXava 5 application from an iPad the style is the same of the desktop browser, the iPad native style is not shown by default. This is because iPad style only works with standalone modules, that OpenXava 5 does not use by default. If you want to use the native iPad style just follow the above instructions in section Executing standalone modules is no longer available by default to enable standalone modules.
About the support for iPad and tablets we're going to have an unique style that works fine in both desktop and tablet, a responsive style.
Transient classes require an explicit module declaration
For example, if you have a transient class called FilterByMonth with a controller called FilterByMonth and you try the URL /MyApplication/modules/FilterByMonth, it does not work until you declare it in application.xml as following:
Anyways, always it has been needed to declare the modules for transient classes in order to generate portlets, therefore if you work with portals you already have the modules defined.
FINEST log level produces a lot of trace
Until now FINEST log level produced a small amount of trace, but since v5.0 OpenXava generates a lot of trace with FINEST. Therefore you have to edit your xava.properties file and change:
javaLoggingLevel=FINEST
By:
javaLoggingLevel=FINE
If you want to keep a moderate amount of trace.
Until v4.9.1 the OpenXava projects created from OpenXavaTemplate had FINEST configured by default, since v5.0 they have FINE.
Objects class from org.openxava.util removed
This class conflicts with the java.util.Objects class of Java 7. Instead of qualifying the class everywhere we prefer to rename it to XObjects. In your code just replace Objects by XObjects, as following:
Objects.execute(myObject, "doSomething");
Instead now you have to write:
XObjects.execute(myObject, "doSomething");
AccessTracking removed from the distribution
You can continue using AccessTracking without any problem, just execute the updateOX ant target from AccessTracking after updating OpenXava.
URL used by ModuleTestBase includes a parameter by default
This only affects you if you overwrite getModuleURL() to add parameters. In that case just change ? by &:
publicclass MyModuleTest extends ModuleTestBase {
...
@OverrideprotectedString getModuleURL(){// return super.getModuleURL() + "?myParameter=5"; // With ? in v4.x.xreturnsuper.getModuleURL() + "&myParameter=5";// With & in v5.0}}
@Digits annuls default scale
When @Digits is specified default scale is ignored even if fraction is not specified. It means that if you write:
With v4.x it had 2 fraction digits because default scale for BigDecimal is 2. However, since v5.0 it has 0 digits, because not specifying fraction is equals to write fraction=0. This allows you to have BigDecimal numbers with 0 for fraction part, but it could do than some of your existing numeric properties stop to use 2 fraction digits. To fix it, just specify fraction explicitly, thus:
Scale defined in default-size.xml and from @Column and @Digits was ignored when formatting. We fixed it. Yes, the number formatting works better, but you have to adapt your tests. For example, if you use a BigDecimal with no annotations you should change:
assertValue("myBigDecimalNumber", "20");
by this:
assertValue("myBigDecimalNumber", "20.00");
Migration from OpenXava 4.9 to OpenXava 4.9.1
Method getFrame() access modifier changed
The access modifier of the method getFrame() in org.openxava.web.style.Style was changed from protected to public. If you have classes which overrides getFrame(), then you are required to change its access modifier from protected to public.
Migration from OpenXava 4.8.1 to OpenXava 4.9
PDF report headers can use several lines
This does not affect your application code at all. However, if you verify the PDF content in your automatic tests maybe you need to make some adjustments. For example, the next code would fail if the header of the report now use 2 lines instead of 1:
assertPopupPDFLinesCount(5);// Maybe now there are 6 lines, because the header uses 2 lines
CustomReport controller renamed to MyReport
It's unlikely that you need to change your code at all, because this is a controller for internal use of 'My reports' dialog and available only since OpenXava 4.6. However, if you have used actions of CustomReport controller in your jUnit tests you have to rename them to MyReport.
Migration from OpenXava 4.8 to OpenXava 4.8.1
Hidding a member whose name is the same of its container section
We have fixed View.setHidden() to work with sections too, it already worked with groups but not with sections. Therefore, if you have a view like this one:
Where the remarks property is inside a remarks section. Until now if you write this:
getView().setHidden("remarks", true);
You hid the remarks property, however since OpenXava 4.8.1 you'll hide the remarks section. In this case, if you still want to hide the property and not the section you should rename the section, as following:
This is because Gallery editor now uses a dialog instead of a plain view. Moreover, the controller for read only Gallery is Close instead of Return. It's unlikely that you need to change your code at all. However, if you have used this action in jUnit tests you will need to rename it.
Migration from OpenXava 4.6.1 to OpenXava 4.7
Action ExtendedPrint.customReport renamed to ExtendedPrint.myReports
It's unlikely that you need to change your code at all, because this is an action from Typical (so always present) and available only since OpenXava 4.6. However, if you have used this action in jUnit tests, @Action or IChainAction, you will need to rename it.
Method getSelected() of Tab and TabBaseAction deprecated, now we will use getSelectedKeys()
The getSelected() method of Tab and TabBaseAction has been deprecated, instead we have getSelectedKeys(), this method return the keys (Map) from the selected elements.
In most cases getSelected() works well, but if there are some row out of the range of load rows it malfunctions. E.g.: first we select a row, afterwards we order by any column and then we leave this row out of the range of loaded rows. If we use getSelected() we don't get this row, but using getSelectedKeys() we do it.
We have to change in our code:
int[] selected = tab.getSelected();for(int i = 0; i < selected.length; i++){Map key = (Map) tab.getTableModel().getObjectAt(selected[i]);
....
}
by:
Map[] selected = tab.getSelectedKeys();for(int i = 0; i < selected.length; i++){Map key = selected[i];
....
}
Migration from OpenXava 4.6 to OpenXava 4.6.1
Messages in i18n files with no arguments are formatted in the standard way
Really this is a bug fix, but it can affect your i18n messages if they contain apostrophes, so you have to change:
my_message=It can't be in that way
by
my_message=It can''t be in that way
Note, you have to change ' by ''.
Migration from OpenXava 4.5.1 to OpenXava 4.6
No issues.
Migration from OpenXava 4.5 to OpenXava 4.5.1
Custom editors must specify tabindex attribute
In order to be in the correct tab order the editors must specify tabindex="1" in its HTML code, thus:
<inputid="<%=propertyKey%>"
name="<%=propertyKey%>" class="<%=style.getEditor()%><%=numericClass%>"
type="<%=inputType%>"
tabindex="1" <!-- Now, you have put this-->
...
/>
Migration from OpenXava 4.4.x to OpenXava 4.5
Pure select in baseCondition of @Tab now must use JPQL syntax and not SQL
Since v4.5 OpenXava uses JPA to obtain tabular data, before it used SQL. It means that when you use baseCondition to write the complete select you have to use the JPQL syntax, SQL is no longer supported.
That is, if your select is like this one:
baseCondition =
"select e.number, e.description, f.description " +
"from Subfamily e, Family f " +
"where e.familyNumber = f.number"
The syntax of JPQL and SQL is very alike, usually you will not need to do big changes other that using property and entity names intestad of column and table names. You have to use e as alias for the main entity.
The condition of @DescriptionsList now uses JPQL syntax and not SQL
Since v4.5 OpenXava uses JPA to obtain the data for the combos, so you have to use JPQL syntax in condition. If you use not too complicated conditions and use ${propertyName} instead of column name, surely you do not need to do any change. However, maybe you need to do some change, specially if you use column names. For example, the next code no longer work:
@DescriptionsList(// It does not works because THINGID is a column name, so JPA does not recognized it
condition="${thing.number} = (SELECT THINGID FROM ${Thing} WHERE name = 'CAR')")
The solution is using property names instead of column names, in this case changing THINGID by number is enough to fix the problem:
@DescriptionsList(// It works because we use the property name, number, instead of THINGID
condition="${thing.number} = (SELECT number FROM ${Thing} WHERE name = 'CAR')")
Another option is to write the complete sentence in pure JPQL, given that the ${} are no longer required, as following:
@DescriptionsList(// We can use a pure JPQL query without ${propertyName}
condition="e.thing.number = (SELECT t.number FROM Thing t WHERE t.name = 'CAR')")
If you use JPQL you have to use e as alias for the main entity.
@OnSelectElementAction does not refresh by default its collection
This new behavior produces a much better performance in many cases, specially when you are working with huge collection and selecting an elements does not change the collection data. However, if you have a case when your @OnSelectElementAction changes the collection content you have to refresh the collections explicitly, as following:
publicclass MyOnSelectElementAction extends OnSelectElementBaseAction {publicvoid execute()throwsException{
doSomethingThatModifiesTheCollection();
getView().refreshCollections();// Since v4.5 you have to add this line}}
Migration from OpenXava 4.3.x to OpenXava 4.4
HtmlUnit upgraded from 2.5 to 2.9
HtmlUnit is the library used to simulate a browser from the jUnit tests. It has been upgraded to 2.9 version. HtmlUnit has renamed and dropped some methods and classes, indeed they are always refactoring their library (refactoring is good for applications but not so good for libraries). Probably you do not need to change anything in your jUnit tests because ModuleTestBase hides HtmlUnit, however if you are using the HtmlUnit API directly, using getHtmlPage() from ModuleTestBase for example, maybe you have to adapt some method calls.
Migration from OpenXava 4.2.x to OpenXava 4.3
No issues.
Migration from OpenXava 4.1.x to OpenXava 4.2
No issues.
Migration from OpenXava 4.0.1 to OpenXava 4.1
New action in list and collections (for junit tests)
The list and collections have a new action available for the users (List.sumColumn), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new List.sumColumn action:
From now on there is not a default converter defined in default-converters.xml for java.lang.Boolean and boolean. Really, this does not produce any incompatibility problem in JPA applications, since in these applications the JPA engine does the conversion itself. However, if you have a old XML application, you only have to regenerate the code and everything will work fine, because most database do a good job translating boolean to numeric automatically. Anyways, you can configure your application in order that it works as before, just add the following lines to the converters.xml file in the xava folder of your application:
Remember, adding these lines is rarely necessary, regenerating code must be enough. If you application is a JPA application (the usual case) you do not need to do anything.
Migration from OpenXava 4m6 to OpenXava 4.0
No issues.
Migration from OpenXava 4m5 to OpenXava 4m6
Hibernate updated to Hibernate 3.6
In OpenXava 4m6 the Hibernate engine has been upgraded to Hibernate 3.6 in order to support JPA 2.0. Most of the code works with no modification. However, there are some details maybe you have to modify in your code. Below you will find some of those details.
Additionally, it's hightly advisable that you undeploy your old application from the application server, and deploy it again. That is, delete the old application from webapps folder of Tomcat, before deploying a new version of your application based on OX4m6, thus you will be sure that the old JPA and Hibernate jars are removed. Also remove the .dist folders from your workspace or workspace.dist.
Nonexistent @ManyToOne references used as @Id are no longer supported (Hibernate 3.6)
Hibernate 3.6 does not support nonexistent @ManyToOne references used as @Id. That is, if you have an entity with the next ids:
publicclass Delivery {
@Id @Column(length=5)privateint number;
@Id @ManyToOne(fetch=FetchType.LAZY)private DeliveryType type;// The type must exist in the database always
...
}
The reference to DeliveryType must exist always in the database.
Really, this is a very rare case that you will only face when working against legacy databases designed by programmers of the pre-RDBMS era (like RPG programmers). They sometimes use composite keys that include references to other tables, and when the reference does not exist they put zeroes in the fields. If you face this case you can solve it in some of the next ways:
Create a row in the reference table with 0 as key.
Use a plain property instead of a reference. In this case you can use some special editor for the property.
Allow nulls for the column used as pseudo-foreign-key and change all the zeroes by nulls for that column.
In order to assign an already existing entity to a reference it must be managed (Hibernate 3.6)
That is, in previous versions of Hibernate, you could write:
Delivery delivery = new Delivery();
DeliveryType deliveryType = new DeliveryType();// We create a new DeliveryType,// instead of searching it
deliveryType.setNumber(66);// The DeliveryType 66 already exist in database
delivery.setType(deliveryType);
...
XPersistence.getManager().persist(delivery);
But, this does not work with Hibernate 3.6, instead you have to write it in the next way:
Delivery delivery = new Delivery();
DeliveryType deliveryType = XPersistence.getManager()
.find(DeliveryType.class, 66);// We searh it
delivery.setType(deliveryType);
XPersistence.getManager().persist(delivery);
Entity with only one @ManyToOne reference as key (Hibernate 3.6)
With previous versions of Hibernate you could write the next code in your entity:
@Entity
@IdClass(CustomerContactPersonKey.class)publicclass CustomerContactPerson {
@Id @ManyToOne(fetch=FetchType.LAZY)private Customer customer;// No more @Id fields
...
}
And the reference to it in this way:
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumn(name="CUSTOMERCONTACT")// With no referencedColumnName attributeprivate CustomerContactPerson customerContactPerson;
And it worked fine. However, with Hibernate 3.6 this does not work. Fortunately, there is a way of achieving the same effect. Just write your entity in this way:
@Entity// @IdClass is no longer usedpublicclass CustomerContactPerson
implements java.io.Serializable{// Must implement Serializable
@Id @ManyToOne(fetch=FetchType.LAZY)private Customer customer;// No more @Id fields
...
}
And the reference in this way:
@ManyToOne(fetch=FetchType.LAZY)
@JoinColumns({
@JoinColumn(name="CUSTOMERCONTACT",
referencedColumnName="CUSTOMER_NUMBER")// referencedColumnName is mandatory})private CustomerContactPerson customerContactPerson;
CharBooleanType Hibernate type does not work (Hibernate 3.6)
CharBooleanType type (and some other Hibernate types) has been deprecrated, even more, they do not work fine in Hibernate 3.6. If you have a type that extends from CharBooleanType, you must rewrite it extending AbstractSingleColumnStandardBasicType. See the SiNoType in org.openxava.types package.
Discriminator throws duplicate Id (Hibernate 3.6)
Entities used for table per class inheritance using discriminator which field is also an @Id, will throw a duplicate id error. Suppose that you have an entity description like this case:
This would work without problem in 3.4, but will complain in 3.6 (and I believe in 3.5 too). You have to use a Hibernate annotation @DiscriminatorOptions like this:
Method getProperty() of ModuleTestBase has been renamed to getXavaJUnitProperty(). So, if you use it in your test you have to rename the method calls, as following:
String host = getProperty("host");// Until v4m5// Must be replace withString host = getXavaJUnitProperty("host");// Since v4m6
This change was needed to allow using Groovy to write JUnit tests.
Migration from OpenXava 4m4 to OpenXava 4m5
Navigation controller is not added automatically
Until now Navigation controller (with the previous - home - next actions in detail mode) was added automatically to all modules with detail and list. From now on, this controller is no longer added implicitly. This is not a problem since Typical extends it, but if you have a detail - list module with no Typical controller, then you have to add Navigation explicitly:
<modulename="ChangeProductsPrice"><modelname="Product"/><controllername="Navigation"/><!-- You have to add this --><controllername="ChangeProductsPrice"/></module>
New split mode - jUnit changes
In addition to detail and list, now we have a new mode, split, that allows to show the list and the detail at the same time. This feature does not produce any incompatibility at application level, but if you use assertActions() in your tests maybe you have to add this new action:
String[] listActions = {"Print.generatePdf",
"Print.generateExcel",
"CRUD.new",
"CRUD.deleteSelected",
"Mode.detailAndFirst",
"Mode.split", // YOU HAVE TO ADD THIS"List.filter",
"List.customize",
"List.orderBy",
"List.viewDetail",
"List.hideRows",
};
assertActions(listActions);
If you do not like this new split mode, you can remove it from your aplication adding the next entry in xava.properties:
defaultModeController=DetailList
In this case the mode controller is not Mode but DetailList, this implies that you have to change your junit tests:
// execute("Mode.list"); // NO if defaultModeController=DetailList in xava.properties
execute("DetailList.list");// OK if defaultModeController=DetailList in xava.properties
New CRUD.deleteRow action - jUnit changes
The CRUD.deleteSelected action has been split into CRUD.deleteSelected and CRUD.deleteRow. If you used CRUD.deleteSelected with row argument, you have to change it by CRUD.deleteRow:
// execute("CRUD.deleteSelected", "row=2"); // NO, since 4m5
execute("CRUD.deleteRow", "row=2");// YES
Moreover, given that CRUD.deleteRow is available by default for all module, if you use assertActions() in your tests maybe you have to add it to the list of actions.
View is not editable by default
From now on when a module is initialized the View object is not editable. This is no big deal because the new and search actions set the correct editable state of the view. But if you have a custom new or search action maybe you have to modify them to set the editable state explicitly:
publicclass MySearchAction extends ViewBaseAction {publicvoid execute()throwsException{
...
getView().setKeyEditable(false);// You have to call setKeyEditable()
getView().setEditable(true);// and setEditalbe() explicitly
...
}}
Migration from OpenXava 4m3 to OpenXava 4m4
CRUD.search now uses a dialog - jUnit changes
The CRUD.search action now uses a dialog to entry the search data. This means that all your junit tests that uses CRUD.search will fail. That is, if you have a test like the next one:
It does not work now. You must rewrite it. To do it, you have 2 options. The first one is to adapt your test to the new CRUD.search action behavior:
execute("CRUD.search");// It shows a dialog
setValue("number", "1");
execute("Search.search");// It does the search and close the dialog
assertValue("description", "Number one");
The second option is changing "CRUD.search" by "CRUD.refresh", since the old CRUD.search has been renamed as CRUD.refresh:
setValue("number", "1");
execute("CRUD.refresh");// Instead of CRUD.search
assertValue("description", "Number one");
Moreover, given that CRUD.refresh is available by default for all modules, if you use assertActions() in your tests maybe you have to add it to the list of actions.
Migration from OpenXava 4m2 to OpenXava 4m3
MapFacade.getValues() includes the model name in the result
MapFacade.getValues() now includes the model name in the result, with an entry with the key MapFacade.MODEL_NAME. If you use the standard OpenXava classes (such as View or PropertiesManager) everything will work fine, but if you have your custom code maybe it fails because this new unexpected entry. In this case you have to remove the entry from the values, in this way:
Map values = MapFacace.getValues("Person", key, members);
values.remove(MapFacade.MODEL_NAME);// Maybe you need this line
Classes.getSimpleName() method dropped
The method getSimpleName() from Classes has been removed. Use getSimpleName() from Class available from Java 5 instead.
Change this:
Classes.getSimpleName(theClass);
by this:
theClass.getSimpleName();
Migration from OpenXava 4m1 to OpenXava 4m2
Attributes show-dialog and hide-dialog dropped from <action/>
The declarative way to show a dialog of 4m1 has been replaced by a programmatic one in v4m2. The new way is more flexible and requires less code, though the real reason to make this change is that the declarative way requires that developer touches his controllers.xml any time an improvement or change is done in standard OX actions about dialogs. That is, with the declarative way many improvements in OX requires a lot of migration instructions for the developer in order to upgrade his application. With the new programmatic approach, the developer only has to upgrade its OX version and enjoy, without touching his application.
The bad news is that you have to rewrite your dialog code, now instead of marking your action with show-dialog and hide-dialog, you must use showDialog() and closeDialog() methods. Compare the new way with the old way for more details
Collections use dialogs to edit, view and add details - Actions changes
All actions that extends from CollectionBaseAction or CollectionElementViewBaseAction retain its original behavior, so you do not need to do any change in most of your collection actions. But, if you have some detail action that extends directly from ViewBaseAction maybe you have to change the way you access to the parent view. Remember that now you are inside a dialog:
publicclass MyCollectionDetailAction extends ViewBaseAction {publicvoid execute()throwsException{
...
getView().setValue("name", "Pepe");// Now getView() is the dialog view
getPreviousView().setValue("name", "Pepe");// getPreviousView() is the// view has opened the dialog
closeDialog();}}
That is, maybe you have to change getView() by getPreviousView() in some of your action.
Collections use dialogs to edit, view and add details - jUnit changes
It does not affect to your application code, but given that the collection bevahior has changed, you have to adapt your junit tests.The main difference is that the user now uses a dialog to edit the detail line of the collection, so the rest of the actions and values of the main user interface are not available, just because a modal dialog is used.
Now the members of the detail view are in the root of the view, so you must remove the collection prefix when reference to a collection element member:
// details is the name of the collection
setValue("details.quantity", "6");// Now WRONG! You have to remove 'details'
setValue("quantity", "6");// CORRECT! Without collection name
Also the actions available on editing a collection element (so inside a dialog) do not use any argument:
If you want to access to the actions or members of the main view, you have to close the dialog first:
execute("Invoice.editDetail", "row=1,viewObject=xava_view_section1_details");
assertValue("quantity", "234");
closeDialog();// Needed before executing CRUD.save
execute("CRUD.save");
When you save the collection element the dialog is closed, so if you want to add another detail you have to open the dialog again:
execute("Collection.save");// This closes the dialog
execute("Collection.new", // It's needed to call to 'new' again, to open the dialog"viewObject=xava_view_section1_details");
In nested collections you have to change the value of viewObject argument of the row actions, again because now it inside of a dialog that is itself the root view:
execute("Collection.new",
"viewObject=xava_view_deliveryPlaces_receptionists");// WRONG!
execute("Collection.new",
"viewObject=xava_view_receptionists");// CORRECT! Only the last// nested collection name
This does not only appies to viewObject but also to other references to a nested collection in action argument. See the next example:
// WRONG: Using "deliveryPlaces.receptionists", the full qualified name
setConditionValues("deliveryPlaces.receptionists", newString[]{"J"});
execute("List.filter", "collection=deliveryPlaces.receptionists");
assertCollectionRowCount("deliveryPlaces.receptionists", 1);
assertValueInCollection("deliveryPlaces.receptionists", 0, 0, "JUAN");// CORRECT: Using "receptionists", the simple name
setConditionValues("receptionists", newString[]{"J"});
execute("List.filter", "collection=receptionists");
assertCollectionRowCount("receptionists", 1);
assertValueInCollection("receptionists", 0, 0, "JUAN");
In general, if your test fails try to remove the collection name as prefix from member name, action argument, etc.
Row action in collection of entities is by default view and not edit
You have not to change the application code, but only the test code:
// Only for collections of entities with no @AsEmbedded
execute("Collection.edit",
"row=0,viewObject=xava_view_customers");// WRONG! 'edit' is not longer used
execute("Collection.view",
"row=0,viewObject=xava_view_customers");// CORRECT! Now 'view' action is used
This also implies that the view for element has not editable the key properties and has no delete action. Maybe you have to adapt your test:
// Inside the dialog that displays the collection element
assertEditable("number");// WRONG! Key fields are not editable
execute("Collection.remove");// WRONG! 'remove' action are not available
This change does not apply to collection with @AsEmbeddable, CascadeType.REMOVE or CascadeType.ALL.
Migration from OpenXava 3.1.4 to OpenXava 4m1
BaseAction implements IModuleContextAction
BaseAction now implements IModuleContextAction, so if some of your actions implement it you have to rewrite the setContext() method using super.setContext(). In this way:
publicclass MyAction extends BaseAction implements IModuleContextAction {publicvoid setContext(ModuleContext context){super.setContext(context);// You must add this linethis.context= context;}}
Another option is to remove the implements IModuleContextAction and the setContext() method, and to use getContext(), protected method from BaseAction to access to the context.
The xava_currentReferenceLabel session object removed
Note: This change is not needed if you update directly to 4m2 or better, because since 4m2 injecting using <use-object /> in a non-existing property does not fail, but only produces a simple warning.
The xava_currentReferenceLabel session object is not longer used; so it has been removed from default-controllers.xml. This object was used by reference search actions, so if you have your custom search action you have to remove the reference to xava_currentReferenceLabel in your controllers.xml, just as shown the next code:
<controllername="MyReference"><actionname="search"hidden="true"show-dialog="true"class="org.openxava.test.actions.MySearchAction"image="images/search.gif"><use-objectname="xava_view"/><use-objectname="xava_referenceSubview"/><!-- This line must be removed<use-object name="xava_currentReferenceLabel"/>--><use-objectname="xava_tab"/></action></controller>
Also it's convenient for search actions and other reference actions to use show-dialog="true" (show-dialog has been dropped in v4m2) in order to show the searching in a dialog, such as the standard OX search actions.
Migration from OpenXava 3.1.3 to OpenXava 3.1.4
AccessTracking table schema changed
In the AccessTracking project the schema of the table for access record has changed:
USER now is USER_NAME
You have to change your current table if you want to update to the AccessTracking 3.1.4
This change is for working in databases with no support for USER as column name.
Migration from OpenXava 3.1.1 to OpenXava 3.1.2/3.1.3
No issues.
Migration from OpenXava 3.1 to OpenXava 3.1.1
HTML elements id generation changed for support multimodule page support
In order to support several module in the same portal page; OX, since v3.1.1, changes the way the HTML ids are generated. This has no effect in our application code since direct manipulation of HTML elements is rare in a typical OpenXava application. However, we need to do some little change in our junit tests.
When you use xava.keyProperty as argument in an action inside a junit test, you will not use xava.ModelName as prefix anymore. That is you have to change:
Just deleting xava.Delivery in this case.
To avoid a laborious migration OpenXava still support the old style for all actions of Reference controller.
Also if you inspect directly the HTML document using the ids, you have to decorate the ids with the decorateId() method. That is, if you have something as this:
You use here decorateId(). Also note the you have to remove the prefix xava.Formula.
Migration from OpenXava 3.0.3 to OpenXava 3.1
JavaScript code of editors must be moved from JSPs to custom-editors.js
If some of your custom editors define JavaScript functions inside the JSP, you have to move them to a file with name custom-editors.js (maybe you need to create it) in the web/xava/js folder of your project. Note: Since v4m3 you can put the JavaScript code for the editors in any file, the name does not matter, in the folder web/xava/editors/js. In this way you can have one or more files for each editor, and easily to include third party libraries.
That is, if you have an editor called googleMapEditor.jsp with a JavaScript function called showMap(), just in this way:
<script>function showMap(v){
...
}</script><!-- JSP code here -->
You have to move it to custom-editors.js, in this way:
Call to method View.refreshCollections() when collection data are modified
Since OpenXava 3.1 only modified data in the view are refreshed. When the user click on an action of a collection the collection is automatically refreshed, but if your action is outside of the collection then there is no way to know that the collection data have been modified. In this case you need to call explicitly to View.refreshCollections(). For example:
// It's not a collection actionpublicclass TranslateAllCarrierNameAction extends ViewBaseAction {publicvoid execute()throwsException{for(Iterator it=Carrier.findAll().iterator(); it.hasNext();){
Carrier c = (Carrier) it.next();
c.translate();// Carrier is modified,// these data are show currently in a collection of the view}
getView().refreshCollections();// To refresh the data of the// displayed collections}}
That is, maybe you need to add getView().refreshCollections() if the collection data are not refreshed after executing your action.
More libraries needed in MANIFEST.MF (only for EJB2)
Edit the file build/ejb/META-INF/MANIFEST.MF, and add the next files ./lib/slf4j-api.jar ./lib/slf4j-jdk14.jar ./lib/javassist.jar to the jar list.
This only applied if you are using EJB (generating an EAR). Look at OpenXavaTest/build/ejb/META-INF/MANIFEST.MF for a complete and up-to-date list of jars.
Migration from OpenXava 3.0.2 to OpenXava 3.0.3
HttpUnit replaced by HtmlUnit for junit tests using ModuleTestBase
HttpUnit has been replaced by HtmlUnit for junit tests based on ModuleTestBase. The main reason for this is the lack of AJAX support from HttpUnit.
Most of your current junit test based on ModuleTestBase will continue working without touching them. HtmlUnit works as a real browser, allows you to do better testing, but there are some little changes that maybe you need to do to your test in some special cases.
These are the changes in ModuleTestBase:
and the link in the page has keyProperty=xava.Carrier.warehouse.number, that is, it's not exactly equal; in the case of the HttpUnit it works, but in the case of the HtmlUnit it does not work. You cannot execute actions that are not available to the users by means of links or buttons, moreover your test must execute the action exactly in the same way that the user do it.
The methods allowDuplicateSubmit() and click() has been removed
Until now, when you want to simulate an user click you needed a code like this:
Calling to allowDuplicateSubmit() is mandatory before to use click(). The click() method throw the events associated to the button or link but does not work well in many cases. From now on, using HtmlUnit, the execute() just simulates a click(), and does it well, so click() and allowDuplicateSubmit() are no longer needed. If you have a code as the above one, you can replace it for something as this:
execute("MyController.myAction");
Method getForm() returns a HtmlForm
The protected method getForm() of ModuleTestBase that before returned a WebForm of HttpUnit now returns a HtmlForm of HtmlUnit. If you are using it in some test you must rewrite your test. Fortunately this method is rarely used.
Method getConversation() replaced by getWebClient()
The protected method getConversation() of ModuleTestBase that before returned a WebConversation() of HttpUnit has been replaced by getWebClient() method of HtmlUnit that retuns a WebClient. If you are using it in some test you must rewrite your test. Fortunately this method is rarely used.
When you want to fill the 4th element and the 2nd one was a combo (an enum or boolean). Note that you need to put a blankspace in the first one, really in all before the combo. This tricky, needed because of HttpUnit, is no longer needed. Now you can write this:
Without bother about blankspaces. Though spaces are still allowed.
Migration from OpenXava 3.0.1 to OpenXava 3.0.2
Object not found message includes search key values (for junit tests)
This can requires some slight changes in your junit tests. You must change a code as this in your test:
assertError("Object of type Invoice does not exists with that key");
by
assertError("Object of type Invoice does not exists with key Year:2008, Number:1");
Hibernate for user preferences is not longer used
Now Java Preferences are used for storing user preferences. OpenXavaDS and openxava-db are no longer needed.
So you must remove TabUserPreferences.hbm.xml and openxava-hibernate.cfg.xml from the persistence folder of your project.
Migration from OpenXava 3.0 to OpenXava 3.0.1
Validation annotations now are Hibernate Validator constraints
Customer c = new Customer();
c.setNumber(1);
c.setName("JUANITO");// We left remarks property empty
XPersistence.getManager().save(c);
XPersistence.commit();
The code works with OX3.0, but fails with OX3.0.1, because in OX3.0.1 the @Required constraint is enforced when you save using JPA. In OX3.0, and older, validation was applied only when you save using OpenXava (con MapFacade, or OX standard action).
To fix this case, for example, you need to fill the remarks property before save.
Slight improvement in CRUD action 'new'
Now the new action automatically actives the initial section. This can break some junit tests. For example, if you have this code:
execute("Sections.change", "activeSection=2");
...
execute("CRUD.new");
setValue("propertyInSection2", "the value");// This property is in section 2
In this case you have to return to the section 2 explicitly:
execute("Sections.change", "activeSection=2");
...
execute("CRUD.new");// You must add the next line, because after 'new' we are in section 0
execute("Sections.change", "activeSection=2");
setValue("propertyInSection2", "the value");// This property is in section 2
Migration from OpenXava 2.2.5 to OpenXava 3.0
Default persistence provider is JPA
Since v3.0 OpenXava uses JPA by default for persistence. If you want to continue using Hibernate as persistence provider in your application just put the next line in the xava.properties file of your project:
Now the methods of MapFacade do not throw RemoteException but SystemException, that is a runtime exception.
This has little repercussion on your code, but if you have a code like this:
These two lines were two transaction. If the invoice creation fails the customer was saved. That is, MapFacade had an autocommit police.
From now on MapFacade is not autocommit by default, that is, the above case will have only a transaction, commited by OX at the end of the action or test. Now, if fails invoice creation customer creation will not be done.
This can change slightly the behaviour of your actions in case of fails, but only if your actions do several call to MapFacade. If you want to preserver the old behaviour you have two options.
First option: add the next line to your properties/xava.properties file:
mapFacadeAutoCommit=true
Second option: commit the transaction manually. For example, the above code can be write in this way:
Schema for the images table of IMAGES_GALLERY stereotype
Now the schema for the images table is specified specified separately, that is, before you write this in your configuration properties file:
images.table=XAVATEST.IMAGES
Now you write this instead:
images.schema=XAVATEST
images.table=IMAGES
Migration from OpenXava 2.2.2 to OpenXava 2.2.3
Labels of list mode and collections are qualified (for junit tests)
Labels for list mode and collection now are qualified, that is if you have a property customer.name, before the label was Name, and now is Name of Customer. This can be affect some of your junit test, that is, if you have:
assertLabelInList(2, "Name");// for customer.name
now must write:
assertLabelInList(2, "Name of Customer");// for customer.name
AccessTracking table schema changed
In the AccessTracking project the schema of the table for access record has changed:
TABLE now is TABLE_NAME
DATE now is ACCESS_DATE
TIME now is ACCESS_TIME
You have to change your current table if you want to update to the AccessTracking 2.2.3
This change is for working in databases with no support for TABLE, DATE and TIME as column names.
Migration from OpenXava 2.2.1 to OpenXava 2.2.2
No issues.
Migration from OpenXava 2.2 to OpenXava 2.2.1
MoneyFormatter (for jUnit tests)
A money formatter is applied by default for format/parser all values of stereotype MONEY, now all money data is always displayed with 2 decimal digits. Therefore you will need to adapt your junit test changing lines as this one:
assertValue("amount", "20");
by this one:
assertValue("amount", "20.00");
Or, if your prefer the old formatting style you can deactivate the formatter or use another editing your editors.xml file.
Action 'Mode.list" not available when the user navigate to another view (for junit tests)
When the user navigates to another view (for example to create or modify a reference) the link for go to list mode is not present now. Maybe you need to change your junit test.
For example in this junit code:
execute("Reference.createNew", "model=Family2,keyProperty=xava.Product2.family.number");
assertAction("Mode.list");// Since 2.2.1 it fails
The assertAction("Mode.list") has to be removed.
Migration from OpenXava 2.1.5 to OpenXava 2.2
Default behaviour for collection of entities changes
Now, when user click on 'Add' in a collection the entities, he goes to a list where he can choose some entities to add. This may cause that your current JUnit test fails. You need to do a simple modification; simply change code like this in your JUnit test:
execute("Collection.add", "viewObject=xava_view_customers");
assertValueInList(4, 0, getCustomer1().getName());
assertValueInList(5, 0, getCustomer2().getName());
checkRow(4);
checkRow(5);
execute("AddToCollection.add");
assertMessage("2 element(s) added to Customers of Seller");
assertCollectionRowCount("customers",2);
Default behaviour for collection of aggregates changes
Now, when a detail of a collection is saved, the view of the detail is not hidden, this may cause that your current JUnit test fails. You need to do a simple modification; simply change code like this in your JUnit test:
execute("Collection.save", "viewObject=xava_view_section1_details");
execute("Collection.new", "viewObject=xava_view_section1_details");// To remove
That is, remove the "Collection.new" call, because after save the detail, the "new" action is automatically executed, thus the user interface is ready to enter a new detail.
Migration from OpenXava 2.1.4 to OpenXava 2.1.5
No issues.
Migration from OpenXava 2.1.3 to OpenXava 2.1.4
New actions in collections (for junit tests)
The collections have some new actions available for the users, therefore if you test for all presents actions in your junit tests, you need to modify it in order to take in account the new actions.
That is, if you have something as this in your junit test code:
The ant target generarPorltets has been removed from OpenXava/build.xml because now it's exactly equal to generatePortlets. Therefore, if you have in your build.xml something like this:
Since 2.1.3 if a key property of type int, long or short has no value in the view when it is parsed is parsed with null (without value), and not as zero. This has no effect in final user, but possibly you need to modify some JUnit test. For example if you have in a test case:
publicvoid testSomething()throwsException{
assertValue("number", "");
execute("MyControllers.myAction");// This does not change number value
assertValue("number", "0");// because OX parse empty string as 0 (until 2.1.2)
...
}
You now have to write in this way:
publicvoid testSomething()throwsException{
assertValue("number", "");
execute("MyControllers.myAction");// This does not change number value
assertValue("number", "");// because now (since 2.1.3) OX parse empty string as null
...
}
Migration from OpenXava 2.0.4 to OpenXava 2.1
WebSphere projects
If you deploy your projects in WebSphere you need to do the next little changes:
First, in the file hibernate/hibernate.cfg.xml of you project add the next blue marked code:
wtpBuild ant target is dropped from OX; you can use 'rebuild' ant target instead. Calling automatically to an ant target from Eclipse Builder is slow, therefore maybe you prefer to call manually to 'rebuild' ant target on demmand (when the XML code of your OX application is changed).
Migration from OpenXava 2.0.3 to OpenXava 2.0.4
Parse of numeric values
Now data values of type Number (Integer, BigDecimal, Short, etc) and Boolean (not boolean) are parsed as null if in the User Interface are in blank. Before numeric blank field was parsed as 0. This change does not produce big incompatibility problems because default-converters.xml defines the real conversion before to store in database (the real important matter). That is, this change affects only displaying. You incompatibility issues maybe the next one:
The user interface application will display clear fields instead of 0, when the form is reset
In junit test maybe you receive a blank when before it was a 0
If you use View.getValue() for a Number it can be null
API changes
Dates.clonWithoutTime() is renamed to Dates.cloneWithoutTime()
Migration from OpenXava 2.0.2 to OpenXava 2.0.3
No events on-change when searching are thrown
OpenXava Reference Guide (in the section 7.5) says that CRUD.searchByViewKey does not throw any on-change event, and CRUD.searchExecutingOnChange throw all on-change events. But because of a bug in ox2.0.2 (and previous) the CRUD.searchByViewKey threw on-change events of keys in the references, and CRUD.searchExecutingOnChange does not threw CRUD.searchExecutingOnChange of key in the references. This issue is fixed, therefore if your code rely in this erroneus behaviour you will need to adapt it.
Setting value for references (in combos) with compose key in JUnit tests
Setting value for references (in combos) with compose key in JUnit tests must be done using POJOs, now the use of EJB2 primary key is not supported.
See documentation in Migration from OpenXava 1.2.1 to OpenXava 2 below.
Migration from OpenXava 2.0.1 to OpenXava 2.0.2
Action Collection.hiddenDetail has been renamed to Collection.hideDetail in controllers.xml. You have to rename the action inside your junit tests.
Migration from OpenXava 2.0 to OpenXava 2.0.1
No issues.
Migration from OpenXava 1.2.1 to OpenXava 2
Setting value for references (in combos) with compose key in JUnit tests
So far, to set the value to a reference displayed as description-list (as combo), and mapped in database using multiple columns, you write:
DrivingLicenceKey key = new DrivingLicenceKey();
key.setType("C ");
key.setLevel(1);
setValue("drivingLicence.KEY", key.toString());
But, if you uses a pure POJOs version, without Key classes, you have to write:
DrivingLicence key = new DrivingLicence();
key.setType("C ");
key.setLevel(1);
setValue("drivingLicence.KEY", key.toString());
It's better to use the last way, because it's valid for POJOs and EJBs.
Hibernate: References with not null columns as foreign key
In EJB version if you have a reference to another entity that has primitive types as key, the code is generated in a way that no null is saved to database, even if you assign null to your reference.
In hibernate version if you assign null to the reference, null values are saved in database.
Of course, the behaviour of hibernate version is more correct, but you can in hibernate avoid null in database just using a converter in the reference mapping (see section 6.3 of Reference Guide).
That is, maybe you need to add some converters to your references in order to migrate your application from EJB2 to Hibernate.
Changing the active section
xava_activeSection is not longer used for changing the active section. Now if you want to change the active section you must to call to method setActiveSection of the desired view (org.openxava.view.View).
IAggragetOidCalculator
The setContainerKey method is renamed to setContainer. And its semantic changes too. Now the container object is received instead of the key. In this way this calculator is consistent in EJB2 and POJO (without key classes) versions.
Migration from OpenXava 1.2 to OpenXava 1.2.1
Hibernate generation
Now when the EJB code generation is done, the hibernate code generation is executed too (although the hibernate version still does not work at 100%).
Although you use only EJB version, you have to make this little adaptation in your project:
Create the folder hibernate in your project.
Create the file hibernate.cfg.xml inside hibernate folder.
In spanish versión PEQUEÑA now is PEQUENA. This is for avoid problems with ISO-8859-1 versus UTF-8.
Migration from OpenXava 1.1 to OpenXava 1.2
Generated code
Now EJB remote interface has the suffix Remote, and the business interface generated for each component (for example ICustomer) has no all methods of the remote interface.
This is for allowing to the future version 2 of OpenXava work with EJB and Hibernate in the same project and at same time.
In order to adapt you code to this, you must:
Delete all generated code
Regenerate all EJB code
Build all
Search and correct all syntax error
For correct syntax error you can change code in this way:
Customer customer = CustomerUtil.getHome().findByName("PEPE");String name = customer.getName();
By this:
ICustomer customer = CustomerUtil.getHome().findByName("PEPE");String name = customer.getName();
If you use specific EJB methods then you need cast to remote interface:
That is, change Customer by ICustomer when possible, if not possible change Customer by CustomerRemote.
JUnit tests
On deleting an object in a CRUD OpenXava now shows a javascript windows to confirm, instead of changing to another controller. Hence in your tests in order to remove an object from CRUD module you only need use execute("CRUD.delete"). In this case 'yes' is assumed as confirmation answer.
Others
Change the name of packages-ejb.properties in gen-src-xava to packages.properties (or you can simply remove packages-ejb.properties and regenerate code).
Migration from OpenXava 1.0 to OpenXava 1.1
APIs
MetaView.getMetaViewCollection now is MetaView.getMetaCollectionView
MetaView.getMetaViewReference now is MetaView.getMetaReferenceView
JUnit tests
Message 'Object deleted successfully' is change by '{0} deleted successfully'. Hence it's required to change the asserts of this messages.
Migration
How to update your project to the latest OpenXava?
Migration from OpenXava 5.8.1 to OpenXava 5.9
New actions in collections (for JUnit tests)
The collections have new actions available for the users (CollectionCopyPaste.cut and CollectionCopyPaste.paste), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new CollectionCopyPaste.cut action. CollectionCopyPast.paste is hidden by default, so you can ignore it. Moreover, List.sumColum now is always present even if the collection is empty:Booleans are rendered with their label instead of a check in lists
Until now when a boolean was true in the list, the cell shows a check icon and if it is false nothing. From now on, if the boolean is true its label will be shown in the cell, that is for a property named paid, "Paid" will be shown in the cell. This change does not require any modification in your application code, however maybe you have to change some of your JUnit tests for lists and collections. For example, if you have the next line in your test:You should change it by:
If the property label is "Paid".
And for the false case, you should change:
By:
On the other hand if you want to keep the old behavior, just add the next entry in your editors.xml file:
Note the use of BooleanIconListFormatter for list formatter.
Welcome page and Sign In page are separated
Now the content of welcome.jsp is shown when you go to the root of the application. welcome.jsp fills all the page, so you should modify your current welcome.jsp to include the <head>, import the needed CSSs and include a link to the Sign In page (m/SignIn). Look at Addons/web/naviox/welcome.jsp as example.Migration from OpenXava 5.8 to OpenXava 5.8.1
No issues.Migration from OpenXava 5.7.1 to OpenXava 5.8
New actions in list mode (for JUnit tests)
The list mode has new actions available for the users (List.changeColumnName and ImportData.importData), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new List.changeColumnName and ImportData.importData actions:Delete action is not available while creating a new element (for JUnit tests)
In v5.8 when the user clicks on New the Delete action is hidden. This does not affect your application code but if you use assertActions() in your tests maybe you have to adapt them:Search action no longer available in detail mode (for JUnit tests)
If you use assertActions() in your tests you should adapt them:If you use CRUD.search in your test you can change it by CRUD.refresh, that is change:
By:
Moreover, if you want that the search action comes back use the new SearchForCRUD controller that just contains the classic seach action. To define a module with search in application.xml add the SearchForCRUD controller:
Another option si to define it in controllers.xml in this way:
Even if you add the search action back with SearchForCRUD you have to change your JUnit tests because search is no longer in CRUD but in SearchForCRUD. Therefore you have to change:
By:
Also we have a TypicalWithSearch controller that have all the Typical action plus search, just as the old Typical. If you want to use it by default write the next code at the beginning of your application.xml:
Modules with no rows starts executing new action (for JUnit tests)
You should touch JUnit tests with modules without rows, because they now starts in detail mode. For example, you should change a code like this:If the module has no rows, now it starts in detail mode so the first line will fail. We can just change to list mode at the beginning:
Or if you test goes directly to detail mode, like in this example, just remove the first part of the test:
Migration from OpenXava 5.7 to OpenXava 5.7.1
No issues.Migration from OpenXava 5.6.1 to OpenXava 5.7
Action List.changeConfigurationName renamed as List.changeConfiguration (for JUnit tests)
The list action List.changeConfigurationName now is List.changeConfiguration, therefore if you test for all present actions in your junit tests, you need to modify the name of this action:Improved default properties for list and collections (for JUnit tests)
Until now when @Tab for list, or @ListProperties for collections, is omitted by default OpenXava shows all the plain properties of the entity. Since v5.7 when @Tab/@ListProperties is not present the properties to show are the plain ones, the ids of the references, the name, description or title of the references or if not present the first not id property of the reference. Moreover, the plain properties that are just oids are excluded.For example, if we have this class without @Tab:
In previous versions we get in list: year, number, date, files
In v5.7 we get: year, number, date, customer.number, customer.name
If you have JUnit tests againts entities without @Tab maybe you'll have to adapt them.
@NewAction no longer define the add action in regular @OneToMany collections
Since v5.7 @OneToMany collections without cascade REMOVE have available at the same time a 'New' action to create new elements and a 'Add' action to add elements from existing ones. Before v5.7 only the 'Add' action was available and it could be defined using @NewAction. Now we have a new annotation, @AddAction, for 'Add' action and we use the old @NewAction only for 'New' action.You should change @NewAction by @AddAction in collections without cascade REMOVE. Change:
By:
Collections of entities with no REMOVE cascade allow to edit the elements (for JUnit tests)
You don't need to change your application code, just adapt your JUnit tests changing:By:
Note, now it's not "Collection.view" but "Collection.edit".
Automatic label for references in list optimized (for JUnit tests)
When in a list we have a property from a reference and the property name is "name", "description" or "title", the property name is omitted, OpenXava shows just the reference name. That is, instead of "Name of Customer" now is just "Customer". This does not affect your application code at all, but if you test list labels in your JUnit tests you should adapt them.Change this:
By this:
Migration from OpenXava 5.6 to OpenXava 5.6.1
No issues.Migration from OpenXava 5.5.1 to OpenXava 5.6
The action ExtendedPrint.myReports is no longer available by default (for JUnit tests)
Therefore if you test for all present actions in your JUnit tests, you need to modify it removing ExtendedPrint.myReports from the list:Though the action is not available by default, it still exists in OpenXava and works perfectly. Indeed there is a new controller TypicalExtendedPrint to facilitate its use. If you want to continue using the My reports feature just change Typical by TypicalExtendedPrint in your application.xml and controllers.xml, even you can declare it as default controller.
New action in list (for junit tests)
The list has a new action available for the users (List.changeConfigurationName), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new List.changeConfigurationName action:Migration from OpenXava 5.5 to OpenXava 5.5.1
Needed to call super inside setUp() of tests before using JPA
Since v5.5.1 the JPA initialization ModuleTestBase tests is done in the setUp() method, so if you use JPA inside a setUp() method you have to call super before. That is, if you have a code like this in your test:Change it by:
Migration from OpenXava 5.4.1 to OpenXava 5.5
@DescriptionsList combos are not longer HTML select (only if you use HtmlUnit API)
Combos for @DescriptionsList are now created with a HTML input text plus some JavaScript code and CSS to emulate a combo. This does not require any change in your application code, it even does not require that you change your jUnit tests if you just use the ModuleTestBase provided methods. However, if you use the HtmlUnit API directly, for example by means of getHtmlPage() or getWebClient() in your tests, and you manage a @DescriptionList combo. Then you have to adjust your code, changing:By:
Migration from OpenXava 5.4 to OpenXava 5.4.1
No issues.Migration from OpenXava 5.3.2 to OpenXava 5.4
Icons instead of images for actions
Since v5.4 the standard actions of OpenXava use icons from Material Design Icons instead of gif or png images. The image attribute of <action/> in controllers.xml continue to work as always, however we have a new attribute icon that is the one used in the standard actions. The effect is that in your application all the standard actions will use the new monochrome icons and your own actions will use the old colorful gif and png images. This mix could be a little ugly, to fix it just change image by icon in your actions. For example, change:By this:
To see all available icons look at Material Design Icons.
On the other hand, if your prefer to continue with the old fashion color icons, just add the next line in xava.properties:
Then all the actions, included the standard ones, will use the old colorful images.
Migration from OpenXava 5.3.1 to OpenXava 5.3.2
No issues.Migration from OpenXava 5.3 to OpenXava 5.3.1
HSQLDB jar moved from OpenXavaTest to OpenXava
If you reference this jar you have to change the path. For example, if you uses HSQLDB in some of your projects, you should change in updateSchema target of your build.xml this:<property name="schema.path" value="../OpenXavaTest/lib/hsqldb.jar"/>By this:<property name="schema.path" value="../OpenXava/lib/hsqldb.jar"/>Migration from OpenXava 5.2.1 to OpenXava 5.3
Hibernate upgraded to 4.3
If you use JPA API or basic use of Hibernate API you have to do nothing. However, if you use advanced Hibernate features maybe this upgrade affects you.For example, if you have your own Hibernate types (UserType), you have to change in your type definition this:
By:
And this:
By:
Of course, if you call these methods you have to adapt the calling code too. For example, a code like this:
Now it would be:
Note that sending a null for the new extra parameter is enough.
Moreover, instead of Hibernate.INTEGER you have to use IntegerType.INSTANCE.
The way of registering events has changed, it affects you only if you use XML components with the JPA API. In this case you have to remove the event registration from the persistence.xml, as following:
Also if you use XML components you no longer can have a reference used as key if the value does not exist in the referenced table. This case is no longer allowed by Hibernate. This case has never been supported in JPA. You should think in a different way of solving your issue, such as adding an autogenerated key or creating the corresponding row in the referenced table.
With Hibernate 4.3 the default way of releasing connections has changed, so you could find a "Could not open connection error". To avoid it add the next entry to your persistence.xml:
Hibernate Validator 3 dropped
Until now we have included both, the old Hibernate Validator 3 and the latest Hibernate Validator version in OpenXava distribution for maximum backward compatibility. Unfortunately Hibernate 4.3 does not support Hibernate Validator 3, so we have to remove it from OpenXava.If you just use validation annotations as @Max, @Length, @Size, etc. it's enough to change the imports, change:
By:
In the case of @Digits apart of changing the above imports you have to change the parameter names, changing this:
By:
You cannot longer use InvalidStateException of Hibernate Validator 3. Therefore, if you use it to throw a validation error from your entity or action you have to change it by other exception. For example, a code like this:
Now it could be written in this way:
If you have defined your own validator with the Old Hibernate Validator you should rewrite it using the Bean Validation standard. Don't worry, converting it is very easy. In your annotation change @ValidatorClass by @Constraint and add groups() and payload(), thus:
And in the validator class change this:
By:
And this:
By:
You can keep the rest of your code as is.
@Required, @PropertyValidator and @EntityValidator are Bean Validation restriction
Before, they were Hibernate Validator 3 restrictions. If you do your own commit and try to catch the validation exception you have to change the exception to catch. If you have a code like this:You should write it in this way:
Prefix for JNDI in older Tomcats
Hibernate 4.3 uses a different way for looking the JNDI resources that works fine with Tomcat 7.0.27 (and better) and Tomcat 6.0.36 (and better) but fails with previous versions. This is not a bug of Hibernate but a Tomcat bug. Fortunately, there is a trick to make the new Hibernate works even with older Tomcat versions, just add a // to the JNDI name. That is, if you're using a Tomcat version previous to 7.0.27 or 6.0.36 just change in your persistence.xml this:By this:
And in hibernate.cfg.xml change this:
By this:
Note the // before comp. If you use JNDI names in other places you shoud change them too. The good thing is that newer Tomcat versions also work in this way, so if you use always this notation your application will work in any Tomcat.
EL libraries upgrade for Tomcat 6
If you're using Tomcat 6 copy el-api.jar and jasper-el.jar from the Tomcat lib folder included in OpenXava (or any Tomcat 7) to the lib folder of your Tomcat 6. This is required by the latest Hibernate Validator version.Automated Business Logic (ABL) library dropped
Unfortunately, ABL does not support Hibernate 4.3. Moreover, ABL has been discontinued since 2012, so it will not support Hibernate 4.3 in the future. Therefore, we have not other option but removing ABL from OpenXava distribution. Fortunately, moving the logic in ABL annotations to Java code is easy. For example, if you have an ABL logic class like this:Remove the above class and move the calculation in @Formula annotation to a @PrePersist and @PreUpdate method in the entity, thus:
Furthermore, you have to remove the next entry from your persistence.xml:
schema.path required in generateSchema ant target
This affects to generateSchema not to updateSchema. If you have a generateSchema target in your build.xml, add schema.path, as following:Migration from OpenXava 5.2 to OpenXava 5.2.1
Entity from View has nulls for non-existing references
Until v5.2 all references of the entity obtained via getView().getEntity() have value, even if the references do not exist. It was producing a very odd bug because JPA tries to save transient objects as references. Since v5.2.1, empty references are null, this is more natural (it works in the same way when you get the object from database) and it solves the above bug.If you have code that relies in this behavior you must change it. That is, you have to make changes like the next one:
By:
Migration from OpenXava 5.1.x to OpenXava 5.2
HtmlUnit upgraded to 2.15
If you use HtmlUnit directly from your jUnit test by means of getHtmlPage() or getWebClient() you should adapt your code to the new HtmlUnit 2.15 API. For example, you should change:By:
And:
By:
And many more things. Unfortunately, HtmlUnit team refactor their library in each new minor version, so HtmlUnit is never backward compatible.
Migration from OpenXava 5.0.x to OpenXava 5.1
@DefaultValueCalculator dependent on other properties changes its behavior
If you have a default calculator like this one:With versions previous to 5.1 when product.number changes unitPrice is recalculated only if it has not value yet. Since version 5.1 unitPrice is recalculated always that product.number changes.
This new behavior is more natural, so if you do not change anything your user just will have a better behavior for his applications. Anyways, maybe you want that the value would be calculated only the first time, just like before. In this case you should rewrite your logic using @OnChage, that is you should change the above code by this:
Migration from OpenXava 4.9.1 to OpenXava 5.0
User login affects your jUnit tests
Now it's required that the user signs in before executing a module so your current jUnit tests will fail. To solve this disable the login mechanism adding the next entries to your naviox.properties file in properties folder:In this way your tests will run fine without recode them.
Another option is to leave the login mechanism active and to add the login logic in your test:
Executing standalone modules is no longer available by default
When you go to /MyApplication/modules/MyModule with your browser, the module is shown with menus and login included. This is not a problem at all, because the menus are very lightweight and login can be disable with autologinUser and autologinPassword in naviox.properties. Moreover, inside Liferay the modules work as usual.But if for some reason you prefer to work in the old way you can deactivate login and menus and use the old visual style for your modules in OpenXava 5. To do it edit the web.xml file of OpenXava project and remove:
Also change:
By:
And change:
By:
Finally remove:
With the above changes in OpenXava/web.xml you have removed the menus and login. You must execute updateOX ant target to update the web.xml of your project.
For using the visual style of OpenXava 4 add the next entries to xava.properties of your project:
iPad native style is not used by default
When you access to an OpenXava 5 application from an iPad the style is the same of the desktop browser, the iPad native style is not shown by default. This is because iPad style only works with standalone modules, that OpenXava 5 does not use by default. If you want to use the native iPad style just follow the above instructions in section Executing standalone modules is no longer available by default to enable standalone modules.About the support for iPad and tablets we're going to have an unique style that works fine in both desktop and tablet, a responsive style.
Transient classes require an explicit module declaration
For example, if you have a transient class called FilterByMonth with a controller called FilterByMonth and you try the URL /MyApplication/modules/FilterByMonth, it does not work until you declare it in application.xml as following:Anyways, always it has been needed to declare the modules for transient classes in order to generate portlets, therefore if you work with portals you already have the modules defined.
FINEST log level produces a lot of trace
Until now FINEST log level produced a small amount of trace, but since v5.0 OpenXava generates a lot of trace with FINEST. Therefore you have to edit your xava.properties file and change:By:
If you want to keep a moderate amount of trace.
Until v4.9.1 the OpenXava projects created from OpenXavaTemplate had FINEST configured by default, since v5.0 they have FINE.
Objects class from org.openxava.util removed
This class conflicts with the java.util.Objects class of Java 7. Instead of qualifying the class everywhere we prefer to rename it to XObjects. In your code just replace Objects by XObjects, as following:Instead now you have to write:
AccessTracking removed from the distribution
You can continue using AccessTracking without any problem, just execute the updateOX ant target from AccessTracking after updating OpenXava.URL used by ModuleTestBase includes a parameter by default
This only affects you if you overwrite getModuleURL() to add parameters. In that case just change ? by &:@Digits annuls default scale
When @Digits is specified default scale is ignored even if fraction is not specified. It means that if you write:With v4.x it had 2 fraction digits because default scale for BigDecimal is 2. However, since v5.0 it has 0 digits, because not specifying fraction is equals to write fraction=0. This allows you to have BigDecimal numbers with 0 for fraction part, but it could do than some of your existing numeric properties stop to use 2 fraction digits. To fix it, just specify fraction explicitly, thus:
BigDecimal formatting fixed (for jUnit tests)
Scale defined in default-size.xml and from @Column and @Digits was ignored when formatting. We fixed it. Yes, the number formatting works better, but you have to adapt your tests. For example, if you use a BigDecimal with no annotations you should change:by this:
Migration from OpenXava 4.9 to OpenXava 4.9.1
Method getFrame() access modifier changed
The access modifier of the method getFrame() in org.openxava.web.style.Style was changed from protected to public. If you have classes which overrides getFrame(), then you are required to change its access modifier from protected to public.Migration from OpenXava 4.8.1 to OpenXava 4.9
PDF report headers can use several lines
This does not affect your application code at all. However, if you verify the PDF content in your automatic tests maybe you need to make some adjustments. For example, the next code would fail if the header of the report now use 2 lines instead of 1:CustomReport controller renamed to MyReport
It's unlikely that you need to change your code at all, because this is a controller for internal use of 'My reports' dialog and available only since OpenXava 4.6. However, if you have used actions of CustomReport controller in your jUnit tests you have to rename them to MyReport.Migration from OpenXava 4.8 to OpenXava 4.8.1
Hidding a member whose name is the same of its container section
We have fixed View.setHidden() to work with sections too, it already worked with groups but not with sections. Therefore, if you have a view like this one:Where the remarks property is inside a remarks section. Until now if you write this:
You hid the remarks property, however since OpenXava 4.8.1 you'll hide the remarks section. In this case, if you still want to hide the property and not the section you should rename the section, as following:
Migration from OpenXava 4.7.1 to OpenXava 4.8
No issues.Migration from OpenXava 4.7 to OpenXava 4.7.1
Gallery.return action renamed to Gallery.close
This is because Gallery editor now uses a dialog instead of a plain view. Moreover, the controller for read only Gallery is Close instead of Return. It's unlikely that you need to change your code at all. However, if you have used this action in jUnit tests you will need to rename it.Migration from OpenXava 4.6.1 to OpenXava 4.7
Action ExtendedPrint.customReport renamed to ExtendedPrint.myReports
It's unlikely that you need to change your code at all, because this is an action from Typical (so always present) and available only since OpenXava 4.6. However, if you have used this action in jUnit tests, @Action or IChainAction, you will need to rename it.Method getSelected() of Tab and TabBaseAction deprecated, now we will use getSelectedKeys()
The getSelected() method of Tab and TabBaseAction has been deprecated, instead we have getSelectedKeys(), this method return the keys (Map) from the selected elements.In most cases getSelected() works well, but if there are some row out of the range of load rows it malfunctions. E.g.: first we select a row, afterwards we order by any column and then we leave this row out of the range of loaded rows. If we use getSelected() we don't get this row, but using getSelectedKeys() we do it.
We have to change in our code:
by:
Migration from OpenXava 4.6 to OpenXava 4.6.1
Messages in i18n files with no arguments are formatted in the standard way
Really this is a bug fix, but it can affect your i18n messages if they contain apostrophes, so you have to change:by
Note, you have to change ' by ''.
Migration from OpenXava 4.5.1 to OpenXava 4.6
No issues.Migration from OpenXava 4.5 to OpenXava 4.5.1
Custom editors must specify tabindex attribute
In order to be in the correct tab order the editors must specify tabindex="1" in its HTML code, thus:Migration from OpenXava 4.4.x to OpenXava 4.5
Pure select in baseCondition of @Tab now must use JPQL syntax and not SQL
Since v4.5 OpenXava uses JPA to obtain tabular data, before it used SQL. It means that when you use baseCondition to write the complete select you have to use the JPQL syntax, SQL is no longer supported.That is, if your select is like this one:
baseCondition = "select NUMBER, DESCRIPTION, FAMILY.DESCRIPTION " + "from XAVATEST.SUBFAMILY, XAVATEST.FAMILY " + "where SUBFAMILY.FAMILY = FAMILY.NUMBER"You have to rewrite it in this way:baseCondition = "select e.number, e.description, f.description " + "from Subfamily e, Family f " + "where e.familyNumber = f.number"The syntax of JPQL and SQL is very alike, usually you will not need to do big changes other that using property and entity names intestad of column and table names. You have to use e as alias for the main entity.The condition of @DescriptionsList now uses JPQL syntax and not SQL
Since v4.5 OpenXava uses JPA to obtain the data for the combos, so you have to use JPQL syntax in condition. If you use not too complicated conditions and use ${propertyName} instead of column name, surely you do not need to do any change. However, maybe you need to do some change, specially if you use column names. For example, the next code no longer work:The solution is using property names instead of column names, in this case changing THINGID by number is enough to fix the problem:
Another option is to write the complete sentence in pure JPQL, given that the ${} are no longer required, as following:
If you use JPQL you have to use e as alias for the main entity.
@OnSelectElementAction does not refresh by default its collection
This new behavior produces a much better performance in many cases, specially when you are working with huge collection and selecting an elements does not change the collection data. However, if you have a case when your @OnSelectElementAction changes the collection content you have to refresh the collections explicitly, as following:Migration from OpenXava 4.3.x to OpenXava 4.4
HtmlUnit upgraded from 2.5 to 2.9
HtmlUnit is the library used to simulate a browser from the jUnit tests. It has been upgraded to 2.9 version. HtmlUnit has renamed and dropped some methods and classes, indeed they are always refactoring their library (refactoring is good for applications but not so good for libraries). Probably you do not need to change anything in your jUnit tests because ModuleTestBase hides HtmlUnit, however if you are using the HtmlUnit API directly, using getHtmlPage() from ModuleTestBase for example, maybe you have to adapt some method calls.Migration from OpenXava 4.2.x to OpenXava 4.3
No issues.Migration from OpenXava 4.1.x to OpenXava 4.2
No issues.Migration from OpenXava 4.0.1 to OpenXava 4.1
New action in list and collections (for junit tests)
The list and collections have a new action available for the users (List.sumColumn), therefore if you test for all present actions in your junit tests, you need to modify it in order to take into account the new List.sumColumn action:Migration from OpenXava 4.0 to OpenXava 4.0.1
There is not default converter for boolean
From now on there is not a default converter defined in default-converters.xml for java.lang.Boolean and boolean. Really, this does not produce any incompatibility problem in JPA applications, since in these applications the JPA engine does the conversion itself. However, if you have a old XML application, you only have to regenerate the code and everything will work fine, because most database do a good job translating boolean to numeric automatically. Anyways, you can configure your application in order that it works as before, just add the following lines to the converters.xml file in the xava folder of your application:Remember, adding these lines is rarely necessary, regenerating code must be enough. If you application is a JPA application (the usual case) you do not need to do anything.
Migration from OpenXava 4m6 to OpenXava 4.0
No issues.Migration from OpenXava 4m5 to OpenXava 4m6
Hibernate updated to Hibernate 3.6
In OpenXava 4m6 the Hibernate engine has been upgraded to Hibernate 3.6 in order to support JPA 2.0. Most of the code works with no modification. However, there are some details maybe you have to modify in your code. Below you will find some of those details.Additionally, it's hightly advisable that you undeploy your old application from the application server, and deploy it again. That is, delete the old application from webapps folder of Tomcat, before deploying a new version of your application based on OX4m6, thus you will be sure that the old JPA and Hibernate jars are removed. Also remove the .dist folders from your workspace or workspace.dist.
Nonexistent @ManyToOne references used as @Id are no longer supported (Hibernate 3.6)
Hibernate 3.6 does not support nonexistent @ManyToOne references used as @Id. That is, if you have an entity with the next ids:The reference to DeliveryType must exist always in the database.
Really, this is a very rare case that you will only face when working against legacy databases designed by programmers of the pre-RDBMS era (like RPG programmers). They sometimes use composite keys that include references to other tables, and when the reference does not exist they put zeroes in the fields. If you face this case you can solve it in some of the next ways:
In order to assign an already existing entity to a reference it must be managed (Hibernate 3.6)
That is, in previous versions of Hibernate, you could write:But, this does not work with Hibernate 3.6, instead you have to write it in the next way:
Entity with only one @ManyToOne reference as key (Hibernate 3.6)
With previous versions of Hibernate you could write the next code in your entity:And the reference to it in this way:
And it worked fine. However, with Hibernate 3.6 this does not work. Fortunately, there is a way of achieving the same effect. Just write your entity in this way:
And the reference in this way:
CharBooleanType Hibernate type does not work (Hibernate 3.6)
CharBooleanType type (and some other Hibernate types) has been deprecrated, even more, they do not work fine in Hibernate 3.6. If you have a type that extends from CharBooleanType, you must rewrite it extending AbstractSingleColumnStandardBasicType. See the SiNoType in org.openxava.types package.Discriminator throws duplicate Id (Hibernate 3.6)
Entities used for table per class inheritance using discriminator which field is also an @Id, will throw a duplicate id error. Suppose that you have an entity description like this case:This would work without problem in 3.4, but will complain in 3.6 (and I believe in 3.5 too). You have to use a Hibernate annotation @DiscriminatorOptions like this:
And it will work.
Method getProperty() renamed in ModuleTestBase
Method getProperty() of ModuleTestBase has been renamed to getXavaJUnitProperty(). So, if you use it in your test you have to rename the method calls, as following:This change was needed to allow using Groovy to write JUnit tests.
Migration from OpenXava 4m4 to OpenXava 4m5
Navigation controller is not added automatically
Until now Navigation controller (with the previous - home - next actions in detail mode) was added automatically to all modules with detail and list. From now on, this controller is no longer added implicitly. This is not a problem since Typical extends it, but if you have a detail - list module with no Typical controller, then you have to add Navigation explicitly:New split mode - jUnit changes
In addition to detail and list, now we have a new mode, split, that allows to show the list and the detail at the same time. This feature does not produce any incompatibility at application level, but if you use assertActions() in your tests maybe you have to add this new action:If you do not like this new split mode, you can remove it from your aplication adding the next entry in xava.properties:
In this case the mode controller is not Mode but DetailList, this implies that you have to change your junit tests:
New CRUD.deleteRow action - jUnit changes
The CRUD.deleteSelected action has been split into CRUD.deleteSelected and CRUD.deleteRow. If you used CRUD.deleteSelected with row argument, you have to change it by CRUD.deleteRow:Moreover, given that CRUD.deleteRow is available by default for all module, if you use assertActions() in your tests maybe you have to add it to the list of actions.
View is not editable by default
From now on when a module is initialized the View object is not editable. This is no big deal because the new and search actions set the correct editable state of the view. But if you have a custom new or search action maybe you have to modify them to set the editable state explicitly:Migration from OpenXava 4m3 to OpenXava 4m4
CRUD.search now uses a dialog - jUnit changes
The CRUD.search action now uses a dialog to entry the search data. This means that all your junit tests that uses CRUD.search will fail. That is, if you have a test like the next one:It does not work now. You must rewrite it. To do it, you have 2 options. The first one is to adapt your test to the new CRUD.search action behavior:
The second option is changing "CRUD.search" by "CRUD.refresh", since the old CRUD.search has been renamed as CRUD.refresh:
Moreover, given that CRUD.refresh is available by default for all modules, if you use assertActions() in your tests maybe you have to add it to the list of actions.
Migration from OpenXava 4m2 to OpenXava 4m3
MapFacade.getValues() includes the model name in the result
MapFacade.getValues() now includes the model name in the result, with an entry with the key MapFacade.MODEL_NAME. If you use the standard OpenXava classes (such as View or PropertiesManager) everything will work fine, but if you have your custom code maybe it fails because this new unexpected entry. In this case you have to remove the entry from the values, in this way:Classes.getSimpleName() method dropped
The method getSimpleName() from Classes has been removed. Use getSimpleName() from Class available from Java 5 instead.Change this:
by this:
Migration from OpenXava 4m1 to OpenXava 4m2
Attributes show-dialog and hide-dialog dropped from <action/>
The declarative way to show a dialog of 4m1 has been replaced by a programmatic one in v4m2. The new way is more flexible and requires less code, though the real reason to make this change is that the declarative way requires that developer touches his controllers.xml any time an improvement or change is done in standard OX actions about dialogs. That is, with the declarative way many improvements in OX requires a lot of migration instructions for the developer in order to upgrade his application. With the new programmatic approach, the developer only has to upgrade its OX version and enjoy, without touching his application.The bad news is that you have to rewrite your dialog code, now instead of marking your action with show-dialog and hide-dialog, you must use showDialog() and closeDialog() methods. Compare the new way with the old way for more details
Collections use dialogs to edit, view and add details - Actions changes
All actions that extends from CollectionBaseAction or CollectionElementViewBaseAction retain its original behavior, so you do not need to do any change in most of your collection actions. But, if you have some detail action that extends directly from ViewBaseAction maybe you have to change the way you access to the parent view. Remember that now you are inside a dialog:That is, maybe you have to change getView() by getPreviousView() in some of your action.
Collections use dialogs to edit, view and add details - jUnit changes
It does not affect to your application code, but given that the collection bevahior has changed, you have to adapt your junit tests.The main difference is that the user now uses a dialog to edit the detail line of the collection, so the rest of the actions and values of the main user interface are not available, just because a modal dialog is used.Now the members of the detail view are in the root of the view, so you must remove the collection prefix when reference to a collection element member:
Also the actions available on editing a collection element (so inside a dialog) do not use any argument:
If you want to access to the actions or members of the main view, you have to close the dialog first:
When you save the collection element the dialog is closed, so if you want to add another detail you have to open the dialog again:
In nested collections you have to change the value of viewObject argument of the row actions, again because now it inside of a dialog that is itself the root view:
This does not only appies to viewObject but also to other references to a nested collection in action argument. See the next example:
In general, if your test fails try to remove the collection name as prefix from member name, action argument, etc.
Row action in collection of entities is by default view and not edit
You have not to change the application code, but only the test code:This also implies that the view for element has not editable the key properties and has no delete action. Maybe you have to adapt your test:
This change does not apply to collection with @AsEmbeddable, CascadeType.REMOVE or CascadeType.ALL.
Migration from OpenXava 3.1.4 to OpenXava 4m1
BaseAction implements IModuleContextAction
BaseAction now implements IModuleContextAction, so if some of your actions implement it you have to rewrite the setContext() method using super.setContext(). In this way:Another option is to remove the implements IModuleContextAction and the setContext() method, and to use getContext(), protected method from BaseAction to access to the context.
The xava_currentReferenceLabel session object removed
Note: This change is not needed if you update directly to 4m2 or better, because since 4m2 injecting using <use-object /> in a non-existing property does not fail, but only produces a simple warning.The xava_currentReferenceLabel session object is not longer used; so it has been removed from default-controllers.xml. This object was used by reference search actions, so if you have your custom search action you have to remove the reference to xava_currentReferenceLabel in your controllers.xml, just as shown the next code:
Also it's convenient for search actions and other reference actions to use show-dialog="true" (show-dialog has been dropped in v4m2) in order to show the searching in a dialog, such as the standard OX search actions.
Migration from OpenXava 3.1.3 to OpenXava 3.1.4
AccessTracking table schema changed
In the AccessTracking project the schema of the table for access record has changed:- USER now is USER_NAME
You have to change your current table if you want to update to the AccessTracking 3.1.4This change is for working in databases with no support for USER as column name.
Migration from OpenXava 3.1.1 to OpenXava 3.1.2/3.1.3
No issues.Migration from OpenXava 3.1 to OpenXava 3.1.1
HTML elements id generation changed for support multimodule page support
In order to support several module in the same portal page; OX, since v3.1.1, changes the way the HTML ids are generated. This has no effect in our application code since direct manipulation of HTML elements is rare in a typical OpenXava application. However, we need to do some little change in our junit tests.When you use xava.keyProperty as argument in an action inside a junit test, you will not use xava.ModelName as prefix anymore. That is you have to change:
by
Just deleting xava.Delivery in this case.
To avoid a laborious migration OpenXava still support the old style for all actions of Reference controller.
Also if you inspect directly the HTML document using the ids, you have to decorate the ids with the decorateId() method. That is, if you have something as this:
You need to change by the next code:
You use here decorateId(). Also note the you have to remove the prefix xava.Formula.
Migration from OpenXava 3.0.3 to OpenXava 3.1
JavaScript code of editors must be moved from JSPs to custom-editors.js
If some of your custom editors define JavaScript functions inside the JSP, you have to move them to a file with name custom-editors.js (maybe you need to create it) in the web/xava/js folder of your project. Note: Since v4m3 you can put the JavaScript code for the editors in any file, the name does not matter, in the folder web/xava/editors/js. In this way you can have one or more files for each editor, and easily to include third party libraries.That is, if you have an editor called googleMapEditor.jsp with a JavaScript function called showMap(), just in this way:
You have to move it to custom-editors.js, in this way:
And now inside your editor instead of calling to the function in this way:
<input ... onclick="showMap(value)"/>you have to do it qualifiying the function:<input ... onclick="openxava.editors.googleMap.showMap(value)"/>Call to method View.refreshCollections() when collection data are modified
Since OpenXava 3.1 only modified data in the view are refreshed. When the user click on an action of a collection the collection is automatically refreshed, but if your action is outside of the collection then there is no way to know that the collection data have been modified. In this case you need to call explicitly to View.refreshCollections(). For example:That is, maybe you need to add getView().refreshCollections() if the collection data are not refreshed after executing your action.
More libraries needed in MANIFEST.MF (only for EJB2)
Edit the file build/ejb/META-INF/MANIFEST.MF, and add the next files ./lib/slf4j-api.jar ./lib/slf4j-jdk14.jar ./lib/javassist.jar to the jar list.This only applied if you are using EJB (generating an EAR). Look at OpenXavaTest/build/ejb/META-INF/MANIFEST.MF for a complete and up-to-date list of jars.
Migration from OpenXava 3.0.2 to OpenXava 3.0.3
HttpUnit replaced by HtmlUnit for junit tests using ModuleTestBase
HttpUnit has been replaced by HtmlUnit for junit tests based on ModuleTestBase. The main reason for this is the lack of AJAX support from HttpUnit.Most of your current junit test based on ModuleTestBase will continue working without touching them. HtmlUnit works as a real browser, allows you to do better testing, but there are some little changes that maybe you need to do to your test in some special cases.
These are the changes in ModuleTestBase:
Exact arguments for execute() are required
That is, if you write in your test:and the link in the page has keyProperty=xava.Carrier.warehouse.number, that is, it's not exactly equal; in the case of the HttpUnit it works, but in the case of the HtmlUnit it does not work. You cannot execute actions that are not available to the users by means of links or buttons, moreover your test must execute the action exactly in the same way that the user do it.
The methods allowDuplicateSubmit() and click() has been removed
Until now, when you want to simulate an user click you needed a code like this:Calling to allowDuplicateSubmit() is mandatory before to use click(). The click() method throw the events associated to the button or link but does not work well in many cases. From now on, using HtmlUnit, the execute() just simulates a click(), and does it well, so click() and allowDuplicateSubmit() are no longer needed. If you have a code as the above one, you can replace it for something as this:
Method getForm() returns a HtmlForm
The protected method getForm() of ModuleTestBase that before returned a WebForm of HttpUnit now returns a HtmlForm of HtmlUnit. If you are using it in some test you must rewrite your test. Fortunately this method is rarely used.Method getConversation() replaced by getWebClient()
The protected method getConversation() of ModuleTestBase that before returned a WebConversation() of HttpUnit has been replaced by getWebClient() method of HtmlUnit that retuns a WebClient. If you are using it in some test you must rewrite your test. Fortunately this method is rarely used.Easier use of setConditionValue
Before you must write the next code:When you want to fill the 4th element and the 2nd one was a combo (an enum or boolean). Note that you need to put a blankspace in the first one, really in all before the combo. This tricky, needed because of HttpUnit, is no longer needed. Now you can write this:
Without bother about blankspaces. Though spaces are still allowed.
Migration from OpenXava 3.0.1 to OpenXava 3.0.2
Object not found message includes search key values (for junit tests)
This can requires some slight changes in your junit tests. You must change a code as this in your test:by
Hibernate for user preferences is not longer used
Now Java Preferences are used for storing user preferences. OpenXavaDS and openxava-db are no longer needed.So you must remove TabUserPreferences.hbm.xml and openxava-hibernate.cfg.xml from the persistence folder of your project.
Migration from OpenXava 3.0 to OpenXava 3.0.1
Validation annotations now are Hibernate Validator constraints
@Required, @PropertyValidator and @EntityValidator are defined since 3.0.1 as Hibernate Validator contrains. This means that when you save using directly JPA api, these validations are enforced.That is, if you have an entity as this one:
And you run the next code:
The code works with OX3.0, but fails with OX3.0.1, because in OX3.0.1 the @Required constraint is enforced when you save using JPA. In OX3.0, and older, validation was applied only when you save using OpenXava (con MapFacade, or OX standard action).
To fix this case, for example, you need to fill the remarks property before save.
Slight improvement in CRUD action 'new'
Now the new action automatically actives the initial section. This can break some junit tests. For example, if you have this code:In this case you have to return to the section 2 explicitly:
Migration from OpenXava 2.2.5 to OpenXava 3.0
Default persistence provider is JPA
Since v3.0 OpenXava uses JPA by default for persistence. If you want to continue using Hibernate as persistence provider in your application just put the next line in the xava.properties file of your project:MapFacade does not longer throw RemoteException
Now the methods of MapFacade do not throw RemoteException but SystemException, that is a runtime exception.This has little repercussion on your code, but if you have a code like this:
Then you must change the RemoteException by a SystemException:
Moreover, XavaException is now a runtime exception. But this does not requires any change in your code.
Migration from OpenXava 2.2.4 to OpenXava 2.2.5
MapFacade is not autocommit from now on
Until now, when you write:These two lines were two transaction. If the invoice creation fails the customer was saved. That is, MapFacade had an autocommit police.
From now on MapFacade is not autocommit by default, that is, the above case will have only a transaction, commited by OX at the end of the action or test. Now, if fails invoice creation customer creation will not be done.
This can change slightly the behaviour of your actions in case of fails, but only if your actions do several call to MapFacade. If you want to preserver the old behaviour you have two options.
First option: add the next line to your properties/xava.properties file:
Second option: commit the transaction manually. For example, the above code can be write in this way:
Migration from OpenXava 2.2.3 to OpenXava 2.2.4
Schema for the images table of IMAGES_GALLERY stereotype
Now the schema for the images table is specified specified separately, that is, before you write this in your configuration properties file:Now you write this instead:
Migration from OpenXava 2.2.2 to OpenXava 2.2.3
Labels of list mode and collections are qualified (for junit tests)
Labels for list mode and collection now are qualified, that is if you have a property customer.name, before the label was Name, and now is Name of Customer. This can be affect some of your junit test, that is, if you have:now must write:
AccessTracking table schema changed
In the AccessTracking project the schema of the table for access record has changed:- TABLE now is TABLE_NAME
- DATE now is ACCESS_DATE
- TIME now is ACCESS_TIME
You have to change your current table if you want to update to the AccessTracking 2.2.3This change is for working in databases with no support for TABLE, DATE and TIME as column names.
Migration from OpenXava 2.2.1 to OpenXava 2.2.2
No issues.Migration from OpenXava 2.2 to OpenXava 2.2.1
MoneyFormatter (for jUnit tests)
A money formatter is applied by default for format/parser all values of stereotype MONEY, now all money data is always displayed with 2 decimal digits. Therefore you will need to adapt your junit test changing lines as this one:by this one:
Or, if your prefer the old formatting style you can deactivate the formatter or use another editing your editors.xml file.
Action 'Mode.list" not available when the user navigate to another view (for junit tests)
When the user navigates to another view (for example to create or modify a reference) the link for go to list mode is not present now. Maybe you need to change your junit test.For example in this junit code:
The assertAction("Mode.list") has to be removed.
Migration from OpenXava 2.1.5 to OpenXava 2.2
Default behaviour for collection of entities changes
Now, when user click on 'Add' in a collection the entities, he goes to a list where he can choose some entities to add. This may cause that your current JUnit test fails. You need to do a simple modification; simply change code like this in your JUnit test:by this one:
Moreover, now the user can add several entities at once, thus a code as this:
can be done in this way:
Default behaviour for collection of aggregates changes
Now, when a detail of a collection is saved, the view of the detail is not hidden, this may cause that your current JUnit test fails. You need to do a simple modification; simply change code like this in your JUnit test:by this one:
That is, remove the "Collection.new" call, because after save the detail, the "new" action is automatically executed, thus the user interface is ready to enter a new detail.
Migration from OpenXava 2.1.4 to OpenXava 2.1.5
No issues.Migration from OpenXava 2.1.3 to OpenXava 2.1.4
New actions in collections (for junit tests)
The collections have some new actions available for the users, therefore if you test for all presents actions in your junit tests, you need to modify it in order to take in account the new actions.That is, if you have something as this in your junit test code:
you must change it by:
Ant target generarPortlets removed
The ant target generarPorltets has been removed from OpenXava/build.xml because now it's exactly equal to generatePortlets. Therefore, if you have in your build.xml something like this:Must change it by:
Migration from OpenXava 2.1 to OpenXava 2.1.3
JUnit test and key without value parsed as zero
Since 2.1.3 if a key property of type int, long or short has no value in the view when it is parsed is parsed with null (without value), and not as zero. This has no effect in final user, but possibly you need to modify some JUnit test. For example if you have in a test case:You now have to write in this way:
Migration from OpenXava 2.0.4 to OpenXava 2.1
WebSphere projects
If you deploy your projects in WebSphere you need to do the next little changes:First, in the file hibernate/hibernate.cfg.xml of you project add the next blue marked code:
Second, in your configuration file for websphere (for example websphere-as400.properties) you have to add:
Other changes that requires some migration
Migration from OpenXava 2.0.3 to OpenXava 2.0.4
Parse of numeric values
Now data values of type Number (Integer, BigDecimal, Short, etc) and Boolean (not boolean) are parsed as null if in the User Interface are in blank. Before numeric blank field was parsed as 0. This change does not produce big incompatibility problems because default-converters.xml defines the real conversion before to store in database (the real important matter). That is, this change affects only displaying. You incompatibility issues maybe the next one:API changes
Migration from OpenXava 2.0.2 to OpenXava 2.0.3
No events on-change when searching are thrown
OpenXava Reference Guide (in the section 7.5) says that CRUD.searchByViewKey does not throw any on-change event, and CRUD.searchExecutingOnChange throw all on-change events. But because of a bug in ox2.0.2 (and previous) the CRUD.searchByViewKey threw on-change events of keys in the references, and CRUD.searchExecutingOnChange does not threw CRUD.searchExecutingOnChange of key in the references. This issue is fixed, therefore if your code rely in this erroneus behaviour you will need to adapt it.Setting value for references (in combos) with compose key in JUnit tests
Setting value for references (in combos) with compose key in JUnit tests must be done using POJOs, now the use of EJB2 primary key is not supported.See documentation in Migration from OpenXava 1.2.1 to OpenXava 2 below.
Migration from OpenXava 2.0.1 to OpenXava 2.0.2
Action Collection.hiddenDetail has been renamed to Collection.hideDetail in controllers.xml. You have to rename the action inside your junit tests.Migration from OpenXava 2.0 to OpenXava 2.0.1
No issues.Migration from OpenXava 1.2.1 to OpenXava 2
Setting value for references (in combos) with compose key in JUnit tests
So far, to set the value to a reference displayed as description-list (as combo), and mapped in database using multiple columns, you write:But, if you uses a pure POJOs version, without Key classes, you have to write:
It's better to use the last way, because it's valid for POJOs and EJBs.
Hibernate: References with not null columns as foreign key
In EJB version if you have a reference to another entity that has primitive types as key, the code is generated in a way that no null is saved to database, even if you assign null to your reference.In hibernate version if you assign null to the reference, null values are saved in database.
Of course, the behaviour of hibernate version is more correct, but you can in hibernate avoid null in database just using a converter in the reference mapping (see section 6.3 of Reference Guide).
That is, maybe you need to add some converters to your references in order to migrate your application from EJB2 to Hibernate.
Changing the active section
xava_activeSection is not longer used for changing the active section. Now if you want to change the active section you must to call to method setActiveSection of the desired view (org.openxava.view.View).IAggragetOidCalculator
The setContainerKey method is renamed to setContainer. And its semantic changes too. Now the container object is received instead of the key. In this way this calculator is consistent in EJB2 and POJO (without key classes) versions.Migration from OpenXava 1.2 to OpenXava 1.2.1
Hibernate generation
Now when the EJB code generation is done, the hibernate code generation is executed too (although the hibernate version still does not work at 100%).Although you use only EJB version, you have to make this little adaptation in your project:
- Create the folder hibernate in your project.
- Create the file hibernate.cfg.xml inside hibernate folder.
The hibernate.cfg.xml have to be:In addition you have to include the hibernate.dialect property in your configuration files:
XML OpenXava syntax
Migration from OpenXava 1.1 to OpenXava 1.2
Generated code
Now EJB remote interface has the suffix Remote, and the business interface generated for each component (for example ICustomer) has no all methods of the remote interface.This is for allowing to the future version 2 of OpenXava work with EJB and Hibernate in the same project and at same time.
In order to adapt you code to this, you must:
- Delete all generated code
- Regenerate all EJB code
- Build all
- Search and correct all syntax error
For correct syntax error you can change code in this way:By this:
If you use specific EJB methods then you need cast to remote interface:
By this:
That is, change Customer by ICustomer when possible, if not possible change Customer by CustomerRemote.
JUnit tests
Others
Migration from OpenXava 1.0 to OpenXava 1.1
APIs
JUnit tests
CustomReport